Bug 108640 (udev)

Summary: RHEL4: Support Persistent Device Naming (udev) kernel portion
Product: Red Hat Enterprise Linux 4 Reporter: Matt Webbink <mattwebb>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED CURRENTRELEASE QA Contact: Martin Jenner <mjenner>
Severity: high Docs Contact:
Priority: high    
Version: 4.0CC: bjohnson, dkl, harald, katzj, nobody+wcheng, notting, rperkins, sdenham, tao
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
URL: IT_11384
Whiteboard: Kernel
Fixed In Version: 2.6.9-5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-02-27 18:11:15 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 113838    
Attachments:
Description Flags
Fujitsu Oct 2003 Slides none

Description Matt Webbink 2003-10-30 20:49:47 UTC
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.

Comment 2 Susan Denham 2003-11-04 22:22:35 UTC
Does sysfs provide persistent device naming in 2.6?

Comment 3 Susan Denham 2003-11-04 23:05:08 UTC
*** Bug 108795 has been marked as a duplicate of this bug. ***

Comment 4 dff 2003-11-05 00:02:06 UTC
*** Bug 109110 has been marked as a duplicate of this bug. ***

Comment 5 dff 2003-11-05 13:58:40 UTC
*** Bug 109031 has been marked as a duplicate of this bug. ***

Comment 13 Robert Perkins 2004-01-22 19:26:31 UTC
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.

Comment 14 Robert Perkins 2004-01-22 19:27:00 UTC
Created attachment 97184 [details]
Fujitsu Oct 2003 Slides

Comment 15 Bill Nottingham 2004-01-22 19:48:17 UTC
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 18:13:14 UTC
Adding NEC request for udev/USDE- vague request that must be further defined.


Comment 17 dff 2004-01-24 19:36:57 UTC
Amazon is also keenly interested in persistent device naming in the RHEL4 context.

Comment 19 Robert Perkins 2004-03-17 07:03:48 UTC
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 14:16:04 UTC
There has been created a mailing list to discuss this matter:
http://lists.osdl.org/mailman/listinfo/device_naming

udev is under heavy development...

Comment 22 Robert Perkins 2004-04-20 15:04:41 UTC
*** Bug 113399 has been marked as a duplicate of this bug. ***

Comment 23 Tim Burke 2004-04-30 19:48:44 UTC
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