mirror of
https://github.com/freebsd/freebsd-src.git
synced 2024-12-02 04:13:39 +00:00
Untabify pass.
This commit is contained in:
parent
19566a0c18
commit
5485580183
Notes:
svn2git
2020-12-20 02:59:44 +00:00
svn path=/head/; revision=9026
@ -6,57 +6,57 @@ works. It's not very hard to understand. A "fully qualified slice name",
|
||||
that is the name of the file we open in /dev to talk to the slice,
|
||||
is optionally broken into 3 parts:
|
||||
|
||||
First you have the disk name. Assume we have two SCSI
|
||||
drives in our system, which gives us `sd0' and `sd1'.
|
||||
First you have the disk name. Assume we have two SCSI
|
||||
drives in our system, which gives us `sd0' and `sd1'.
|
||||
|
||||
Next you have the "Slice" (or "Master Partition") number,
|
||||
as seen in the Partition Editor. Assume that our sd0 contains
|
||||
two slices, a FreeBSD slice and a DOS slice. This gives us
|
||||
sd0s1 and sd0s2. Let's also say that sd1 is completely devoted
|
||||
to FreeBSD, so we have only one slice there: sd1s1.
|
||||
Next you have the "Slice" (or "Master Partition") number,
|
||||
as seen in the Partition Editor. Assume that our sd0 contains
|
||||
two slices, a FreeBSD slice and a DOS slice. This gives us
|
||||
sd0s1 and sd0s2. Let's also say that sd1 is completely devoted
|
||||
to FreeBSD, so we have only one slice there: sd1s1.
|
||||
|
||||
Next, if a slice is a FreeBSD slice, you have a number of
|
||||
(confusingly named) "partitions" you can put inside of it.
|
||||
These FreeBSD partitions are where various filesystems or swap
|
||||
areas live, and using our hypothetical two-SCSI-disk machine
|
||||
again, we might have something like the following layout on sd0:
|
||||
Next, if a slice is a FreeBSD slice, you have a number of
|
||||
(confusingly named) "partitions" you can put inside of it.
|
||||
These FreeBSD partitions are where various filesystems or swap
|
||||
areas live, and using our hypothetical two-SCSI-disk machine
|
||||
again, we might have something like the following layout on sd0:
|
||||
|
||||
Name Mountpoint
|
||||
---- ----------
|
||||
sd0s1a /
|
||||
sd0s1b <swap space>
|
||||
sd0s1e /usr
|
||||
Name Mountpoint
|
||||
---- ----------
|
||||
sd0s1a /
|
||||
sd0s1b <swap space>
|
||||
sd0s1e /usr
|
||||
|
||||
Because of historical convention, there is also a short-cut,
|
||||
or "compatibility slice", that is maintained for easy access
|
||||
to the first FreeBSD slice on a disk for those programs which
|
||||
still don't know how to deal with the new slice scheme.
|
||||
The compatibility slice names for our filesystem above would
|
||||
look like:
|
||||
Because of historical convention, there is also a short-cut,
|
||||
or "compatibility slice", that is maintained for easy access
|
||||
to the first FreeBSD slice on a disk for those programs which
|
||||
still don't know how to deal with the new slice scheme.
|
||||
The compatibility slice names for our filesystem above would
|
||||
look like:
|
||||
|
||||
Name Mountpoint
|
||||
---- ----------
|
||||
sd0a /
|
||||
sd0b <swap space>
|
||||
sd0e /usr
|
||||
Name Mountpoint
|
||||
---- ----------
|
||||
sd0a /
|
||||
sd0b <swap space>
|
||||
sd0e /usr
|
||||
|
||||
FreeBSD automatically maps the compatibility slice to the first
|
||||
FreeBSD slice it finds (in this case, sd0s1). You may have multiple
|
||||
FreeBSD slices on a drive, but only the first one may be the
|
||||
compatibility slice!
|
||||
FreeBSD automatically maps the compatibility slice to the first
|
||||
FreeBSD slice it finds (in this case, sd0s1). You may have multiple
|
||||
FreeBSD slices on a drive, but only the first one may be the
|
||||
compatibility slice!
|
||||
|
||||
The compatibility slice will eventually be phased out, but
|
||||
it is still important right now for several reasons:
|
||||
The compatibility slice will eventually be phased out, but
|
||||
it is still important right now for several reasons:
|
||||
|
||||
1. Some programs, as mentioned before, still don't work
|
||||
with the slice paradigm and need time to catch up.
|
||||
1. Some programs, as mentioned before, still don't work
|
||||
with the slice paradigm and need time to catch up.
|
||||
|
||||
2. The FreeBSD boot blocks are unable to look for
|
||||
a root file system in anything but a compatibility
|
||||
slice right now. This means that our root will always
|
||||
show up on "sd0a" in the above scenario, even though
|
||||
it really lives over on sd0s1a and would otherwise be
|
||||
referred to by its full slice name.
|
||||
2. The FreeBSD boot blocks are unable to look for
|
||||
a root file system in anything but a compatibility
|
||||
slice right now. This means that our root will always
|
||||
show up on "sd0a" in the above scenario, even though
|
||||
it really lives over on sd0s1a and would otherwise be
|
||||
referred to by its full slice name.
|
||||
|
||||
Once you understand all this, then the label editor becomes fairly
|
||||
simple. You're either carving up the FreeBSD slices displayed at the
|
||||
|
@ -6,57 +6,57 @@ works. It's not very hard to understand. A "fully qualified slice name",
|
||||
that is the name of the file we open in /dev to talk to the slice,
|
||||
is optionally broken into 3 parts:
|
||||
|
||||
First you have the disk name. Assume we have two SCSI
|
||||
drives in our system, which gives us `sd0' and `sd1'.
|
||||
First you have the disk name. Assume we have two SCSI
|
||||
drives in our system, which gives us `sd0' and `sd1'.
|
||||
|
||||
Next you have the "Slice" (or "Master Partition") number,
|
||||
as seen in the Partition Editor. Assume that our sd0 contains
|
||||
two slices, a FreeBSD slice and a DOS slice. This gives us
|
||||
sd0s1 and sd0s2. Let's also say that sd1 is completely devoted
|
||||
to FreeBSD, so we have only one slice there: sd1s1.
|
||||
Next you have the "Slice" (or "Master Partition") number,
|
||||
as seen in the Partition Editor. Assume that our sd0 contains
|
||||
two slices, a FreeBSD slice and a DOS slice. This gives us
|
||||
sd0s1 and sd0s2. Let's also say that sd1 is completely devoted
|
||||
to FreeBSD, so we have only one slice there: sd1s1.
|
||||
|
||||
Next, if a slice is a FreeBSD slice, you have a number of
|
||||
(confusingly named) "partitions" you can put inside of it.
|
||||
These FreeBSD partitions are where various filesystems or swap
|
||||
areas live, and using our hypothetical two-SCSI-disk machine
|
||||
again, we might have something like the following layout on sd0:
|
||||
Next, if a slice is a FreeBSD slice, you have a number of
|
||||
(confusingly named) "partitions" you can put inside of it.
|
||||
These FreeBSD partitions are where various filesystems or swap
|
||||
areas live, and using our hypothetical two-SCSI-disk machine
|
||||
again, we might have something like the following layout on sd0:
|
||||
|
||||
Name Mountpoint
|
||||
---- ----------
|
||||
sd0s1a /
|
||||
sd0s1b <swap space>
|
||||
sd0s1e /usr
|
||||
Name Mountpoint
|
||||
---- ----------
|
||||
sd0s1a /
|
||||
sd0s1b <swap space>
|
||||
sd0s1e /usr
|
||||
|
||||
Because of historical convention, there is also a short-cut,
|
||||
or "compatibility slice", that is maintained for easy access
|
||||
to the first FreeBSD slice on a disk for those programs which
|
||||
still don't know how to deal with the new slice scheme.
|
||||
The compatibility slice names for our filesystem above would
|
||||
look like:
|
||||
Because of historical convention, there is also a short-cut,
|
||||
or "compatibility slice", that is maintained for easy access
|
||||
to the first FreeBSD slice on a disk for those programs which
|
||||
still don't know how to deal with the new slice scheme.
|
||||
The compatibility slice names for our filesystem above would
|
||||
look like:
|
||||
|
||||
Name Mountpoint
|
||||
---- ----------
|
||||
sd0a /
|
||||
sd0b <swap space>
|
||||
sd0e /usr
|
||||
Name Mountpoint
|
||||
---- ----------
|
||||
sd0a /
|
||||
sd0b <swap space>
|
||||
sd0e /usr
|
||||
|
||||
FreeBSD automatically maps the compatibility slice to the first
|
||||
FreeBSD slice it finds (in this case, sd0s1). You may have multiple
|
||||
FreeBSD slices on a drive, but only the first one may be the
|
||||
compatibility slice!
|
||||
FreeBSD automatically maps the compatibility slice to the first
|
||||
FreeBSD slice it finds (in this case, sd0s1). You may have multiple
|
||||
FreeBSD slices on a drive, but only the first one may be the
|
||||
compatibility slice!
|
||||
|
||||
The compatibility slice will eventually be phased out, but
|
||||
it is still important right now for several reasons:
|
||||
The compatibility slice will eventually be phased out, but
|
||||
it is still important right now for several reasons:
|
||||
|
||||
1. Some programs, as mentioned before, still don't work
|
||||
with the slice paradigm and need time to catch up.
|
||||
1. Some programs, as mentioned before, still don't work
|
||||
with the slice paradigm and need time to catch up.
|
||||
|
||||
2. The FreeBSD boot blocks are unable to look for
|
||||
a root file system in anything but a compatibility
|
||||
slice right now. This means that our root will always
|
||||
show up on "sd0a" in the above scenario, even though
|
||||
it really lives over on sd0s1a and would otherwise be
|
||||
referred to by its full slice name.
|
||||
2. The FreeBSD boot blocks are unable to look for
|
||||
a root file system in anything but a compatibility
|
||||
slice right now. This means that our root will always
|
||||
show up on "sd0a" in the above scenario, even though
|
||||
it really lives over on sd0s1a and would otherwise be
|
||||
referred to by its full slice name.
|
||||
|
||||
Once you understand all this, then the label editor becomes fairly
|
||||
simple. You're either carving up the FreeBSD slices displayed at the
|
||||
|
Loading…
Reference in New Issue
Block a user