Bug 108640 (udev) - RHEL4: Support Persistent Device Naming (udev) kernel portion
Summary: RHEL4: Support Persistent Device Naming (udev) kernel portion
Status: CLOSED CURRENTRELEASE
Alias: udev
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 4.0
Hardware: All Linux
high
high
Target Milestone: ---
: ---
Assignee: Red Hat Kernel Manager
QA Contact: Martin Jenner
URL: IT_11384
Whiteboard: Kernel
Keywords:
: 108795 109031 109110 113399 (view as bug list)
Depends On:
Blocks: 113838
TreeView+ depends on / blocked
 
Reported: 2003-10-30 20:49 UTC by Matt Webbink
Modified: 2008-08-07 01:28 UTC (History)
9 users (show)

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: ---


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

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


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