[ On Sat, October 3, 1998 at 11:08:33 (+1000), Giles Lean wrote: ]
> Subject: Re: Another changer, another changer problem 
>
> On Fri, 2 Oct 1998 20:18:45 -0400 (EDT)  Greg A. Woods wrote:
> 
> > 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.
> 
> Which "guarantee" doesn't apply on HP-UX or Solaris.

Well nobody's ever raised either of them on a pillar of knowledge and
elegance, though generally Sun has always displayed quite a bit more
common sense than HP when it comes to OS design.

> On HP-UX you need both the hardware path and the "instance number"
> to map a device to /dev/dsk/cNtNdN.  Fortunately ioscan is smart
> enough to show you the instance number, and there is lssf to further
> translate but just physical examination won't do it.

"instance number" what the heck kind of stupid idea is that????

> On Solaris (which is SysV, for some values of SysV :-) the picture
> is just as confused as you have to follow the /dev symlinks to find
> the corresponding /devices entries, which I *think* refer to actual
> unchanging hardware paths.  Someone will correct me if I'm wrong.  :-)

The /dev symlinks are really just "convenient aliases" for lazy admins
(though I think there are still admin utilities that refer to these
aliases).

My understanding is that the /device entries are indeed always 100%
equivalent to the physical hardware configuration.  There is some kind
of magic though to do with preserving mappings when installing new
hardware (as you mention below) but luckily I'm not sure how/why that
works.

> > Any changes to the hardware configuration *should* cause the mapping of
> > device nodes to the hardware that moved to change
> 
> The problem is that people don't always add controllers in the same
> order that an OS installation would probe them in.  For better or
> worse both HP-UX and Solaris "preserve" the previous mappings when
> you install new hardware.
> 
> Usually this is a good thing, but it means you have to be on your
> toes when you re-install a machine that has a different hardware
> configuration to what it had when it was first installed.

well this is just the stupid OS trying to be smarter than it ever
possibly can be.  such designs are attacking the wrong problem at the
wrong level.  hiding the true hardware configuration by creating a magic
mapping of /dev names, etc. only adds confusion since as you suggest for
HP-UX it makes it impossible to find the true target of a /dev node
without having the power turned on.

if someone gives me a printout of /etc/fstab and two powered down
machines and tells me to move the spindles associated with one specific
database from one machine to another (assuming a one-2-one mapping of
the databse filesystems and spindles), I should be able to do that
without first powering up the machine.  I should also be able to edit
the /etc/fstab from single user mode on both machines and get it right
without having to copy down the probe messages since I should be able to
know with 100% certainty what /dev nodes correspond to the removed/added
spindles.

> (On HP-UX at least the mappings may be manually specified, if you
> play enough with rmsf and insf.)
> 
> All of these mapping schemes plus BSD hardwiring and even Windows
> registry entries make it hard to move a boot disk from one machine
> to another.  Mostly, this is "unsupported".

Thats why some of us are complaining.  The whole concept of probing and
hard-wiring in the way we have it today is bass ackwards.  The kernel
should always be "generic", and when supporting more dynamic things like
SCSI it should be runtime re-configurable.

The only thing you should have to do when moving a boot disk from one
system to another is to open up /etc/fstab in single user mode and
correct it for the new hardware environment.

Well then there's the same problem with NICs, and so on, but I think you
get the idea.  You should never have to rebuild the kernel.  You
shouldn't even require all the devices to be powerd up at boot time,
especially for external devices such as SCSI targets.  There should
always be some way for the admin to tell the kernel to go out and look
for new devices (or alternately a specific device at a given position in
the hardware map) and then have it deal with it.  Things like SCSI
device drivers should be prepared for anything and everything anywhere
and everywhere.

> This would also provide a better abstraction for what modern smart
> (RAID etc) disk enclosures do.  Having utilities to "create" SCSI
> LUNs always seems strange to me!

LUNs are simply logical volumes -- equivalent to partitions but managed
by the external device, not the device driver in the kernel.  Much
smarter and more flexible (esp. since now you can have multiple
partitions per logical volume!).  The RAID controller could represent
them as separate targets, but this gets really messy, esp. for SCSI, and
of course would be an unnecessary limitation since LUNs are available.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>