Red Hat Bugzilla – Bug 108640
RHEL4: Support Persistent Device Naming (udev) kernel portion
Last modified: 2008-08-06 21:28:33 EDT
Support Persistent Device Naming
This is a major Linux issue for attached enterprise storage. Without such a
implemented, customers run the risk of device names shifting in the event a
target storage array fails or a specific disk fails. This could yield data
corruption as applications would be writing/reading data to the wrong disks.
SITUATION: Simple case - install Red Hat on an rx2600 on the internal drive
number 1 (/dev/sdb, second device) with a drive in slot 0 (/dev/sda). Shut down
the server, pull the drive in slot 0, then try to reboot to the device in slot
1. All of the device names have moved, and the server won't boot. Another case,
lose a device (lun) in the middle of a shared storage e.g., ds2405) in a
cluster, and watch data disappear when you try to reboot.
SOLUTION: Two solutions for persistent device naming are possible:
- implement a Bus/Target/Lun strategy similar to what we are doing on HP-UX today
- implement a WWID strategy similar to what we do with Tru64 UNIX today and
HP-UX 11.23 next year
The B/T/L strategy does not fix the I/O load-balancing through multiple adapters
in a single server, nor the multi-path through either multi-adapters or a
cross-connected (high availability) SAN. However, it would be easier to
implement, and the other issues could be addressed by layered products (like
SecurePath). The source/target naming conventions offered by the WWID scheme
used in Tru64 UNIX today would be better, but would also be much harder to
implement, and may require extensive kernel changes.
The key concern is that as we look at larger than 2P and 4P Integrity servers
and more sophisticated virtualized storage, a strong storage I/O subsystem will
become critical. Right now, this appears to be one of the weakest items for a
Red Hat (or Linux in general) solution.
This is a significant support issue. HP LOSL has considered possible solutions
to this, but we are not currently working on it. We would like to see RH
address this, in a way that would go upstream and be consistent across the
Does sysfs provide persistent device naming in 2.6?
*** Bug 108795 has been marked as a duplicate of this bug. ***
*** Bug 109110 has been marked as a duplicate of this bug. ***
*** Bug 109031 has been marked as a duplicate of this bug. ***
From Fujitsu's slides Oct 2003:
Name Space Stability
Keep hardware name consistent beyond reboot
Even after hardware is removed because of failure or is added, all hardware
names required persistent.
After failed hardware is replaced, replaced hardware can be used as a same name
as failed one.
Focus to NIC / FC and Disks (FC/SCSI connected)
Benefit / Need
Stability at operation: Many scripts to operate and configurations should not be
modified because of adding new hardware, removing old hardware and replacing
Key for large scale server: If this feature would be lacked, data corruption and
data-leak will be happen.
Name Space Stability
Name space stability in /dev
Name space stability in network card name space
nif (Hot Device Identify)
PCI-card Name space stability
Dependency / Assumption
sysfs : fundamental function for name space stability
Name Space Stability
Enhance udev at hot-plug community
Support LUN/SCSI-id based naming in /dev
Support PCI-slot / PCI-bus# based naming
Schedule / What expected to be included in RHEL4
All patches will be available at hot-plug and nif community by end of Mar. 2004.
Created attachment 97184 [details]
Fujitsu Oct 2003 Slides
NIF is completely superflous in the presence of nameif; it's not needed, the
feature is already in RHEL3.
Adding NEC request for udev/USDE- vague request that must be further defined.
Amazon is also keenly interested in persistent device naming in the RHEL4 context.
NEC would like an example of a sample confiuration that is suggested by red hat.
What is the forum for discussing this issue within red hat? Who should we
involve internally within the discussion.
There has been created a mailing list to discuss this matter:
udev is under heavy development...
*** Bug 113399 has been marked as a duplicate of this bug. ***
Setting state to MODIFIED as Arjan says all the kernel portion is done. Note,
the user level portion of the udev feature is separately noted in bug #113838