On Monday 18 February 2008, Martin Michlmayr wrote: > I'm in the process of porting d-i to a number of NAS devices that can > hold 2 or 4 disks. The long standing problem of persistent disk > naming is thus an issue for me. Why exactly is it an issue? As long as all devices are on the same controller (and I'd expect them to be), AFAIK there is no issue: the device naming should be stable across reboots. I can imagine it becoming an issue when you expect these devices to be frequently booted with some external USB storage device connected. That does not mean of course that Debian does not need to solve the persistent device naming issue, but up to now no one has taken the lead in that. Personally I have thought quite a bit about it, but have never been really motivated to work on it, mainly because I find the suggested "solutions" of using the by-path, by-id or by-uuid links extremely ugly. I personally very much would like to avoid those ridiculously long and for end-users completely meaningless links both in my fstab and in my boot options (grub's menu.lst). Add to that the fact that none of them is as persistent as they pretend to be (though probably no worse than the old /dev/hdX ones). I've been thinking about a solution and I guess now is as good a time as any to present it. I'd suggest to create new, really persistent, short and humanly readable device names. I'd like to see these devices named by type with "real" (permanent) hard disks distinguised from removable devices like USB sticks (yes, I know the distinction is thin sometimes). Preferably we'd "reuse" the old /dev/hdX devices, but I expect that that's not possible. An alternative for hard disks would be /dev/diskX; removable USB devices could become /dev/usbX, etc. The main point in my idea is that these links would not be created as soon as a device is detected (as is done now), but only when hardware detection is completed (i.e. when the udev event queue is otherwise empty). udev would then start a final process that checks _all_ of the the existing by-path, by-id and by-uuid links against a "database" of how these new persistent names were previously allocated. It would use heuristics to detect changes (like a disk being moved from SATA port A to B), perform sanity checks against such changes and update the database accordingly. The heuristics would also allow for complete replacements: disk on a certain path has new (not previously seen) id and old id is no longer present in the system. The same mechanism could also work for NICs, which could solve the problem with NIC replacements being assigned increasing numbers: if the NIC now on a certain path has an unknown MAC address and the old MAC is no longer detected, assume the NIC was physically replaced and assign the old persistent name (e.g. eth0) to the new NIC. The database would just be files under /etc/udev and, although partially maintained automatically, they would allow tuning by users. For example, a user should be able to name a hard disk (permanently) connected by USB as /dev/diskX. He should also be allowed to specify that e.g. for a USB stick it is OK to just assign the first available device instead of a persistent device. He should also be able to specify that a device should remain reserved even if it is removed. The database would need to be copied into the initrd, but the heuristics should make it tolerant enough in cases where that database is "outdated" with respect to the one on the root file system. Users may need to update the initrd after changes in hardware or the database, but that's something they also need to do now (for RAID/LVM changes for example). Of course any hardware detected _after_ the initrd stage should never change devices already assigned by the initrd. A lot of details (including device names, the heuristics and configuration options) still need to be worked out of course, but I wonder what people think about the basic idea. Cheers, FJP
Attachment:
signature.asc
Description: This is a digitally signed message part.