Date: Mon, 26 Jun 2006 21:47:07 +0200 From: Paul Schenkeveld <fb-arch@psconsult.nl> To: freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. Message-ID: <20060626194707.GA44234@psconsult.nl> In-Reply-To: <46620.1151326500@critter.freebsd.dk> References: <20060626083828.GA18912@psconsult.nl> <46620.1151326500@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jun 26, 2006 at 12:55:00PM +0000, Poul-Henning Kamp wrote: > In message <20060626083828.GA18912@psconsult.nl>, Paul Schenkeveld writes: > > >I don't want to change the way the world is and certainly not violate POLA > >but just to add another angle to the discussion, life would be nice if > >we had something like: > > > > /dev/ad/0 > > /dev/ad/0/whole_disk > > /dev/ad/0/s1 > > /dev/ad/0/s1a > > /dev/ad/0/s1c > > > >and > > > > /dev/ad/<SERIAL> -> 0 > > This would take a bit of work to implement, currently we do not support > adding DEVFS symlinks in the kernel that point to directory. > > Also, from experience, a lot of weird software needs to learn about > all the '/' you insert in disknames. These arguments are the reason I started out to state that I don't want to "change the way the world is and certainly not violate POLA" but the issue is one I have been thinking about for many years. The way we identify multiple instances of the same type of device in UN*X like systems will always have drawbacks, whichever scheme we choose. Currently, with multiple controllers using the same driver there is always the randomness of which gets detected first by the kernel. If, for example, you have two SCSI controllers, an AHA2940 and an AHA29160, then have to replace one by a newer model which uses the same driver, the numbering may reverse or replacing the first one by a controller which uses a different driver shifts the number of the second controller down by 1. Back in the old days the AT&T 3B had a nice bus with address space divided in ranges per slot so the system always knew in which slot a card was but adding an extra card sometimes meant you had to move an existing card if for example cables and connectors would otherwise become unreachable. Another interesting challenge is the miriad of devices that come and go over time like USB and firewire attached drives, flash cards that slip into the side of a notebook etc. Using a serial number on the device as the OP suggests works until you have to replace broken hardware. And some hardware may not have readable serial numbers at all like flash memory devices. With soft labels stored on a disk the sysadmin at least can control behaviour to some extent but there are certainly corner cases where labels are inconvenient. So having a choice between several different schemes is perhaps the best way to keep many sysadmins happy. > As far as I know, for ATA the problem is solved with ATA_STATIC_ID, > and IMO it is solved better that way. > > This then begs the question if we should instead introduce a generic > DISK_STATIC_ID which all controllers respect ? ATA_STATIC_ID certainly keeps frustration away in many cases and having all drivers behave the same way and change to DISK_STATIC_ID is probably even much better. > For CAM disks I guess this would mean encoding all of (bus,id,lun) > in the device name: > > /dev/da0:0:1 > > or some such. Like /dev/[r]dsk/c0b0t0d0l0s1a as in SysV ;-( Yes this could be handy in some situations where the sysadmin has everything to say about SCSI IDs and LUNs but as I said before, whichever way we choose will solve the problem for some and create a problem for others. Having a choice is good, especially if one can choose which scheme to use by including GEOMs in the kernel or loading them at boot time. The current default of ad*, da* and so on could (IMO should) stay and remain the default to not violate POLA. Two more cents of mine. Regards, Paul Schenkeveld
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060626194707.GA44234>