Untabify pass.

This commit is contained in:
Jordan K. Hubbard 1995-06-04 10:48:46 +00:00
parent 19566a0c18
commit 5485580183
Notes: svn2git 2020-12-20 02:59:44 +00:00
svn path=/head/; revision=9026
2 changed files with 84 additions and 84 deletions

View File

@ -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

View File

@ -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