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 distributions.
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 Feature 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 Activities udev Name space stability in /dev http://linux-hotplug.sourceforge.net nameif Name space stability in network card name space http://linux-hotplug.sourceforge.net nif (Hot Device Identify) PCI-card Name space stability http://sourceforge.net/projects/hdi/ Dependency / Assumption sysfs : fundamental function for name space stability Name Space Stability FJâs TODO 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.
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: http://lists.osdl.org/mailman/listinfo/device_naming 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