DragonFly users List (threaded) for 2006-05
Newbie scsi question
I faced a small problem with Linux recently, saw how Solaris solved
the same problem, and was wondering what DragonFly did.
Disclaimer: I haven't worked with *BSD too much; so this could
potentially be a question best answered by an RTFM. If this is the
case, please point me to the right place, I shall be happy to read up.
Here's the problem:
Consider a typical SAN setup - an FC switch with a couple of JBOD's
and a couple of machines hooked up to the switch.
On linux, the disks from the JBOD are recognised as /dev/sd[a-n]. The
hitch is that the device naming is not consistent across reboots; the
first time around, /dev/sdb could refer to the first disk on the JBOD.
The second time around, you don't know what it points to, as the
assignment of device names to disks depends on the order in which the
disks are recognised at boot time. Of course, there are fixes to this
problem - like devlabel/udev, but they are essentially fixes to a
problem that should never have been there in the first place.
On Solaris, this isn't a problem - the disk's SCSI ID is incorporated
into the device name itself - so you have devices like
/dev/dsk/c3t2100000C502D3790d0s2. This way, the disk name is the same,
regardless of the order in which the disks are recognised at boot
In this kind of a situation, what does DragonFly do to ensure that the
disk names are consistent across reboots?
The easiest way to find out would be to run DF and see - but all boxes
at work that are connected to the SAN are either sparc or amd64 boxes,
and DF doesn't work on either of these yet.