DragonFly bugs List (threaded) for 2007-05
DragonFly BSD
DragonFly bugs List (threaded) for 2007-05
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: vkernel filesystem checks fail


From: Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>
Date: Sat, 26 May 2007 09:36:47 -0700 (PDT)

:I'm kind of feeling uneasy that we now "require" a slice.  I thought that=
:'s just IBM PC legacy?  How about having "vkd0a" =3D=3D "vkd0s0a"?  That =
:would look nice again.  Or maybe the other way around?
:
:cheers
:  simon

    We don't require a slice.  The internal representations haven't changed,
    just the external device names and device numbering.  The external
    names and numbering had to change because of two problems.

    (1) The 'raw' disk also doubled as the labeled disk for the compatibility
	slice.  e.g. you could 'disklabel da0'.  This meant that one
	could not access the raw disk directly as a raw disk without going
	through some hand waving... there was no way to do it without
	the kernel trying to snoop reads and writes for MBR and disklabel
	accesses.

    (2) The 'raw slice' also doubled as partition 'c' in the slice.  e.g. 
	if you look on a 1.8 or earlier system, 'da0s1' had the same device
	number as 'da0s1c'.  This meant that we could not distinguish between
	a raw slice and partition 'c' within a raw slice.

    To fix these problems the compatibility device names and the raw-slice
    devices had to be renumbered.  That is, in 1.9 now, 'da0' really does
    mean a raw disk, the kernel doesn't attempt to process the MBR or
    disklabel or snoop reads and writes or enforce reserved areas.  'da0s0'
    is the faked compatibility slice (aka for disklabeled disks without
    DOS partition tables).  They are separate entities now.  And, in 1.9,
    we distinguish between a raw slice, aka da0s1, and a partition
    specification using a disklabel installed on that slice, aka da0s1{a-p}.

    Pre 1.9 there was no distinction... you could run disklabel on
    anything and the system would silently 'translate' the device to
    a device that was label capable, and the system also tried to snoop
    MBR and label accesses even for the whole-raw-disk device (e.g. da0),
    which created serious confusion.  Now we have real device names
    representing the labelable raw slices (e.g. da0s1), a faked compatibility
    slice (e.g. da0s0) that can be labeled if you don't have an DOS partition
    table (otherwise it aliases the first BSD partition just like the
    compatibility slices used to, but I might remove that feature), the
    partition specifications are properly distinct from the raw slice
    name (da0s1 != da0s1c any more), and the disk layer can now avoid
    snooping labels or scanning the whole partition table until they
    are actually accessed.

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]