svn commit: r195534 - in head: etc/mtree include lib/libcam sbin/camcontrol share/man/man4 sys/cam sys/cam/ata sys/cam/scsi sys/conf sys/dev/advansys sys/dev/ahci sys/dev/aic7xxx sys/dev/amd sys/de...

[Scott Long]

Peter Jeremy wrote:
> On 2009-Jul-12 20:16:26 -0600, Scott Long <scottl at samsco.org> wrote:
>> Another solution is to just bite the bullet and do what I've ultimately
>> wanted to do with disk device names, and create 'diskX' aliases for all
>> direct-access block devices.  This would affect hard disks, memory
>> sticks, logical disks like g_raid things, and things that look like hard
>> disks.
> 
> Having removable devices in the same space as fixed devices _will_ bite
> users when they accidently reboot without pulling out their memory stick
> and find that their disk numbering is all changed.  Wiring physical
> addresses to names might help but can need manual configuration.
> 

The problem is that it's hard to define "removable" these days.
Traditional disks are easy to hot-swap, even in simple desktop systems.
It's also trivial to boot off of a USB drive, or and SDCard.  One thing
that helps is that CAM has always had a mechanism for wiring device
paths to unit numbers, so ahci0:bus0:target0:lun0 can always
be 'da0' no matter what else is plugged in.  It's not a very convenient
interface right now, but it does work.

> I suspect a "one size fits all" approach isn't going to satisfy
> everyone.  Someone with a bog standard desktop with one HDD on SATA
> channel 0 who occasionally plugs in a USB stick has significantly
> different needs to someone running a server with multiple SATA port
> multipliers and multi-pathed fibre-channel who has a USB stick
> permanently installed for booting.  (Note that physical cXtYdZ
> approaches don't mesh cleanly with multi-pathing).

The real problem that we have here is that you want to ensure that the
device that was used to boot the loader and kernel typically needs to
also be the device that is considered for the root filesystem.
Unfortunately, there's no way to correlate BIOS device numbers to OS
driver names and unit numbers.

> 
> IMHO, you need a provision to apply user-selected labels to disks and
> then reference them via those labels (with some sort of fallback to
> handle clashes).  WWN or system-generated labels are too unfriendly to
> use.  (And one of our HP support techs related a story where a
> customer was having some really strange problems on a Tru64 system
> which he eventually tracked down to two of the disks having the same
> WWID - which he agrees should never occur).
> 

Ultimately labels of some sort are the way to go, yes.  I'm not really
thrilled with the unfriendliness of filesystem labels, but maybe that's
the best option at the moment.

Scott