Date: Tue, 27 Jun 2006 14:26:46 +0800 From: "Jia-Shiun Li" <jiashiun@gmail.com> To: freebsd-arch@freebsd.org Subject: Re: Accessing disks via their serial numbers. Message-ID: <1d6d20bc0606262326p3fe063easd121e65b375a5def@mail.gmail.com> In-Reply-To: <20060626194707.GA44234@psconsult.nl> References: <20060626083828.GA18912@psconsult.nl> <46620.1151326500@critter.freebsd.dk> <20060626194707.GA44234@psconsult.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
On 6/27/06, Paul Schenkeveld <fb-arch@psconsult.nl> wrote: > 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. > That's pretty what I think of too. Imagine situation like this that someone has two fxp adapter configured on system. Plugging another one will certainly cause some troubles as he now has problem identify which is fxp0, fxp1, or fxp2. Not all users know how the system probes and enumerate hardware, even if he knows, he still has trouble knowing how hardware are probed on 'his' system as motherboard layouts are different from one to another. Not to mention various versions of i8255[78901] under the same fxp name with different hardware capabilities. The same stands for storages adapters and worse because they have disks as children. Having everything work under the big device tree may be a good solution for unique addressing from programmers' point of view. But 'unique' also means sometimes you have to find out where it is. Serial numbers are unique to the users, and hierarchy names are unique to the system (and admin). There are differences. Take some other examples. If one pull out network adapter and plug it into another slot, in Windows he will get a new "Local Connection 5" and have to re-configure its IP setting. Fortunately the default DHCP works for me in most cases btw. That means Windows use adapter AND slot positions to uniquely identify a network connection for user. AFAIK Fedora uses similar scheme to identify hardwares and keep it in configuration files so kudzu will know when new hardware appears. I guess pjd initially wanted to solve problems like roaming USB disks or get rid of ATA_STATIC_ID. It would be better if you can describe the problems to solve in detail. Because of the nature we need to bind data to specific hardware, for example IP address, mounting points, or files on disks, it is good to have a solution to achieve it instead of depending on the may-change device numbers. Serial number is a good starting point, but it does not necessarily need to go into /dev as many people mentioned all the concerns. One possible solution: providing that uses can get serial number to device node mapping in user space, it could be easy to implement a mechanism, for example in shell scripts, for those who need it. Any comment? In my opinion I have to say, I do not feel it is a good idea to mix the concept of serial numbers and various device attributes with the device names or internal hierarchical representation. They can be coupled but it is probably too closely related if implemented in device tree. Jia-Shiun.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1d6d20bc0606262326p3fe063easd121e65b375a5def>