Subject: Re: Another changer, another changer problem
To: None <email@example.com>
From: Greg A. Woods <firstname.lastname@example.org>
Date: 10/02/1998 20:18:45
[ On Sat, October 3, 1998 at 07:52:10 (+1000), Giles Lean wrote: ]
> Subject: Re: Another changer, another changer problem
> On Thu, 01 Oct 1998 22:18:17 -0500 email@example.com wrote:
> > I really like that. I'm into it. I prefer 'sd0' for stable parts of a
> > system, but I'd love to have /dev/disk/cNtNdN or something similar.
> Even this has problems, as the controller number has the potential to
> migrate if new controllers are added, or the controller number becomes
> dependent on the order of controller installation, a typically nasty
> surprise in a disaster recovery situation when someone re-installs the
> OS and everything "moves".
Oh, of course it does, but that's most emphatically *not* the problem
the /dev/disk/cNtNdN problem is trying to solve. What it does do is
make a guaranteed 100% accurate way of determining what /dev node refers
to what physical device. I.e. you can manually peer in at the back of
the controller card, all the cabling, and the jumpers/switches on the
drives, etc., and be 100% certain what /dev node you must use to access
any given device.
Any changes to the hardware configuration *should* cause the mapping of
device nodes to the hardware that moved to change (eg. if you change the
switches of the devices on your SCSI bus, then you must also make
similar changes to your mount commands in /etc/fstab).
If you want one-to-one mapping between devices and their *contents* then
you need to use unique labeling techniques such as David Maxwell
suggests. The d_packname could easily be used for this purpose.
BTW, in a scheme where mount(8) can mount by label name then I'd expect
the kernel to provide a function that will either directly eliminate the
use of /dev (eg.: openlabel(label, mode) returns a file descriptor), or
will at worst return the appropriate name in /dev for mount to use.
After all the device drivers read the label and thus d_packname already.
Most, if not all, AT&T System V Unix systems do have provisions for
storing a name in the disk label. That name is used by various volume
copy tools, but not used by mount so far as I remember.
Greg A. Woods
+1 416 218-0098 VE3TCP <firstname.lastname@example.org> <robohack!woods>
Planix, Inc. <email@example.com>; Secrets of the Weird <firstname.lastname@example.org>