DragonFly kernel List (threaded) for 2007-06
Re: Decision time.... should NATA become the default for this release?
:Actually, I wonder why we determine the functionality by the minor and no=
:t by the device. Meaning: No CD will *ever* have partitions or MBR, rig=
:ht? But that's a property of the disk device. Why do we reflect this pr=
:operty in the minor number? Just to make it easier to follow from userla=
It has to do with how the disk management layer interprets the access to
the device. I want to have one common disk management layer for all
storage devices. The minor numbers tell the management layer whether
it needs to interpret MBR and/or disklabel information or not. It's
a chicken-and-egg issue... sometimes we want the management layer to
do an I/O to check for an MBR and/or disklabel, and sometimes we don't
want the management layer to do anything at all because a read I/O might
fail (e.g. when using burncd). Even on disks which have MBRs and
labels, sometimes we want to interpret them (when mounting something),
sometimes we don't (when wiping or reinstalling the MBR/disklabel).
This is how the minor number breaks down:
* Partition number (a-j, etc)
The partition number used to be only a few bits. Now it is 8 bits.
This gives us normal partition numbers 0-127 (e.g. once we support
GPT it will come in handy). parition #0 is 'a', #1 is 'b', etc.
The 'whole slice' partition uses partition number 255. This tells
the disk layer to not try to interpret the disklabel at all but
to give you raw access to the contents of a slice.
Whole-disk slices (see below) use partition numbers 128-254 as
special disk management layer bypasses. For example, ACD uses 128
as a raw CD bypass, and uses 129+ for direct audio track access.
* Slice number (s0, whole-disk, s1, s2, s3, s4, etc). There can be up
to 128 slices.
Slice #0 is the compatibility slice (s0). This is a specially
managed slice which is aliased to the first BSD slice found in
the MBR. On media which has no MBR or disklabel, the disk
management layer manages the 'fake' disklabel using the compatibility
Slice #1 is the whole-disk slice. Accessing a device via this slice
using the 'whole-slice' partition number (255) gives you access
to the raw disk through the disk management layer (meaning that
the media size is enforced for reads and writes). Accessing a
device using special partition numbers (128-254) bypass the
disk management layer entirely.
Slice #2 is MBR slice 1 (s1)
Slice #3 is MBR slice 2 (s2)
Slice #4 is MBR slice 3 (s3)
The slice numbering is historical. That's why it looks so messy.
* unit (cd0, cd1, cd2, etc)
It used to be that the 'whole slice' partition was #2 (c). That is,
if you look on a 1.8 box you will notice that ad0s1c uses the same
minor number as ad0s1, meaning the kernel can't tell the difference
and will try to access the disklabel whether you want it to or not.
Under 1.9 the 'whole slice' partition != partition c in the disklabel.
The kernel can tell the difference and will not try to interpret the
disklabel when you are accessing via a whole slice (e.g. like 'ad0s1').
I'm sure there are still a few issues here and there but the jist of
these changes is that we have a lot more partition numbers and slice
numbers available AND the disk management layer is well enough abstracted
that I can implement support for things like GPT.