Date:        Sun, 4 Oct 1998 18:49:04 -0700 (PDT)
    From:        Curt Sampson <cjs@portal.ca>
    Message-ID:  <Pine.NEB.4.02.9810041845380.24222-100000@ascetic.portal.ca>

    Once again, look at the code. We do provide that minor number; it's
    the one attached to /dev/xdNc. That partition need not start at
    zero, and it doesn't matter what's in the disklabel in memory or
    on the disk. The start/end data for that partition are ignored.

That's fine - but it is a waste of a partition label on the disk
that could be used for something more productive.
    
    No. All that means is you're stuffing things the kernel does not
    need to know about into the kernel,

Huh?   You've just said that the kernel already knows magic about the 'c'
partition .. what's more it has to know some kind of magic, or it could
not ever label an unlabelled drive (or simply use an unlabelled disk as if
it were a tape, and write a tar file, or a dump file, there, which sometimes
is very useful).

Aside from compatability with existing /dev/ entries, and labels, which is
no small issue, it seems to be that having the kernel do

	part = DISKPART(dev);
	if (part == 0) {
		/* set up to access the entire drive, ignore label */
	} else {
		/* access via disklabel[part - 1] */
	}

would be much cleaner than the current magic with the 'c' paritition.


And while I'm here, an access scheme that used filesystem labels instead of
any kind of access to the physical location of the drive (which both the
BSD type sdN and the SysV cNtM... do) is clearly the better approach.

It is one of my greater regrets that back in the days when essentially all
discs were on removable packs (ie: before everyone switched to using Eagles
and similar) that I didn't add support for sane use of pack labels.   Once
winchester drive technology, particularly with SMD interfaces, arrived,
the relationship between physical addressing of the drive containing the data
and the data that was being referenced became blurred.  In that environment
the need for being able to reference the data (the filesystem) as an entity,
distinct from the drive in which it happened to be mounted, became somewhat
irrelevant, and the demand to do something lapsed.   Earlier we had systems
with multiple physical receptables (disk drives), and a much larger number of
disk packs, which could be placed into any of the disk drives, and filesystems
could show up in any physical position, and move around without rebooting
the system.   That was when this should have been fixed.   If it had been
you'd all be using logical naming for filesystems now, and loving it, and
those of you who now fear it as "something new, dangerous, and unnecessary"
wouldn't even consider that kind of attitude.

Perhave fortunately, with Zip drives, and Jazz drives, and cdroms (and DVD
to come) all becoming much more popular, the demand for fixing this will
soon be overwhealming, and it will get done.

The aim ought to be, that if I manage to destroy my /usr (or any other
filesystem), I ought to be able to stick a working backup filesystem
(workable, if not necessrily a complete backup) in any one of those
removable pack types of things, and reboot - "the system" (be that the
kernel or user level code) ought to fail to find a correct /usr where it
would normally be found (either it is dead totally, if the drive has died
or I have scribbled all over it, or it fails fsck, or similar) and go on
and notice the alternative in the cdrom drive (or whatever), and mount that
instead.   Using that I can restore the real /usr (perhaps after I have
waited to get and install a replacement piece of hardware, or after usurping
some less necessary filesystem to make space to build a new /usr) and
reboot.   Then the new one will be found, and used, all automatically, and
without anyone ever having to boot single user and attempt to fiddle with
the contents of the fstab file - and so also what the label there for the
physical drive would be (small and neat like sdN or long and pretending
to show the physical address of the hardware, line cNdM...) would be
irrelevant.

To handle multiple filesystems with the same label we just allow the
admin to specify resolution rules (for each filesystem).  Those might allow
something like "prefer fixed drive read/write media, if that isn't available
prefer any read/write media, even if dismountable, and if that isn't available
either, allow any read only media (cdrom etc)".    Then to disambiguate
between equal cost cases of those, prefer the newer (newest if more than 2)
(where that indicates most recently modified).    Of if the admin prefers,
bitch and halt, and allow the admin resolve the duplication by pulling
devices.   Whatever...

Note that it is the filesystems (data sets) that need to be labelled, not
the physical devices - that would be better than we now have, but data sets
move around amongst physical devices, that relationship isn't fixed, and
we ought not be assuming that it is.   Fortunately there's an ideal place
to stick the relevant label ... the "last mounted on" field that already
exists (at least in ufs filesystems, cdroms have other labels, etc) and which
turns out to have almost the ideal semantics.  There's also already a "last
modified time" field in the superblock, so in practice everything we need
exists already.    Add a tool to allow the "last mounted on" field of an
unmounted filesystem to be altered, and all that's needed after that is the
"find the best filesystem with this label and mount it" magic.

Any scheme like this is so many orders of magnitude better than anything
which requires anyone to care about which physical container contains which
filesystem (unless they really want to, of course), let alone which cable
out of the back of the box that container is plugged into today, that it is
hard to even imagine.

kre