Bug 108640 - (udev) RHEL4: Support Persistent Device Naming (udev) kernel portion
RHEL4: Support Persistent Device Naming (udev) kernel portion
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
high Severity high
: ---
: ---
Assigned To: Red Hat Kernel Manager
Martin Jenner
: 108795 109031 109110 113399 (view as bug list)
Depends On:
Blocks: 113838
  Show dependency treegraph
Reported: 2003-10-30 15:49 EST by Matt Webbink
Modified: 2008-08-06 21:28 EDT (History)
9 users (show)

See Also:
Fixed In Version: 2.6.9-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-02-27 13:11:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Fujitsu Oct 2003 Slides (156.50 KB, text/plain)
2004-01-22 14:26 EST, Robert Perkins
no flags Details

  None (edit)
Description Matt Webbink 2003-10-30 15:49:47 EST
Support Persistent Device Naming

This is a major Linux issue for attached enterprise storage.  Without such a
scheme properly 
 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
Comment 2 Susan Denham 2003-11-04 17:22:35 EST
Does sysfs provide persistent device naming in 2.6?
Comment 3 Susan Denham 2003-11-04 18:05:08 EST
*** Bug 108795 has been marked as a duplicate of this bug. ***
Comment 4 dff 2003-11-04 19:02:06 EST
*** Bug 109110 has been marked as a duplicate of this bug. ***
Comment 5 dff 2003-11-05 08:58:40 EST
*** Bug 109031 has been marked as a duplicate of this bug. ***
Comment 13 Robert Perkins 2004-01-22 14:26:31 EST
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
failed hardware.
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
Enhance nif
Stabilize nif
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.
Comment 14 Robert Perkins 2004-01-22 14:27:00 EST
Created attachment 97184 [details]
Fujitsu Oct 2003 Slides
Comment 15 Bill Nottingham 2004-01-22 14:48:17 EST
NIF is completely superflous in the presence of nameif; it's not needed, the
feature is already in RHEL3.
Comment 16 Robert Perkins 2004-01-23 13:13:14 EST
Adding NEC request for udev/USDE- vague request that must be further defined.
Comment 17 dff 2004-01-24 14:36:57 EST
Amazon is also keenly interested in persistent device naming in the RHEL4 context.
Comment 19 Robert Perkins 2004-03-17 02:03:48 EST
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.
Comment 21 Harald Hoyer 2004-04-02 09:16:04 EST
There has been created a mailing list to discuss this matter:

udev is under heavy development...
Comment 22 Robert Perkins 2004-04-20 11:04:41 EDT
*** Bug 113399 has been marked as a duplicate of this bug. ***
Comment 23 Tim Burke 2004-04-30 15:48:44 EDT
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

Note You need to log in before you can comment on or make changes to this bug.