[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Persistent disk naming - wild idea for a solution

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 

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.


Attachment: signature.asc
Description: This is a digitally signed message part.

Reply to: