Bug 168079 - devlabel prefers partition uuid naming over scsi ids
devlabel prefers partition uuid naming over scsi ids
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: devlabel (Show other bugs)
3.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Karel Zak
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-09-12 04:31 EDT by Dan Fruehauf
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-29 08:00:49 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dan Fruehauf 2005-09-12 04:31:20 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050623 Fedora/1.0.4-5 Firefox/1.0.4

Description of problem:
Having multiple SCSI disks with multiple partitions which I want consistent naming for had me use devlabel.
I have 2 of the partitions configured as RAID1 (let it be /dev/md0), let it be sda1 and sdb1.
As long as i don't have a filesystem on my raidset both partitions are OK with devlabel and have devlabel mark them using the scsi_unique_id utility.
However, if i create an ext3 filesystem (perhaps it would be the same for other filesystems as well) on /dev/md0, and rerun devlabel it complains that both /dev/sda1 and /dev/sdb1 has the same uuid.
This is all right as partition_uuid would extract the same uuid from /dev/sda1 and /dev/sdb1 because both devices are mirrored and as far as i'm concerned this is not expected behaviour.

/sbin/devlabel has the following lines :
    # Set the ID
    if [ -n "$dev_suffix" ] && ID=`partition_uuid $1 2>/dev/null` && [ -n "$ID" ]; then
        identifier_type="partition"
        ID="P:$ID"
    elif scsi_unique_id=`scsi_unique_id "$1" 2>/dev/null` && [ -n "$scsi_unique_id" ]; then
...

which means that if we'll give preferance to scsi_unique_id over partition_uuid we could easily solve this problem.


Version-Release number of selected component (if applicable):
devlabel-0.48.03-10

How reproducible:
Always

Steps to Reproduce:
1. Run devlabel to mark 2 partitions on your system (/dev/sda1, /dev/sdb1)
2. Create a raid array (/dev/md0) on /dev/sda1 and /dev/sdb1
3. Activate /dev/md0
4. So far it is all good and devlabel will continue to function properly.
5. Create an ext3 filesystem on /dev/md0 - mke2fs -j /dev/md0
6. Run devlabel (/sbin/devlabel restart) to see how it is confused with /dev/sda1 and /dev/sdb1 complaining it has the same uuid
  

Actual Results:  Links created by devlabel to /dev/sda1 and /dev/sdb1 have been invalidated and removed.

Expected Results:  Those links should have remained so normal operation could continue.

Additional info:
Comment 1 Karel Zak 2005-10-11 09:38:37 EDT
I think you can use --mutilpath option in situation when you have same
filesystem  on both devices (without filesystem it's bad idea, because there are
two different devices). 

Your suggestion with SCSI ID preference over UUID is good solution for you, but
not for the others who expect (and use) preference to UUID. 


Comment 2 Dan Fruehauf 2005-11-03 08:26:50 EST
--multipath does the work but those devices are not multipath - as I said - they
are 2 different devices and I expect a different behavior.
Relying on SCSI ID is much more reliable than filesystem UUID as we're trying to
devlabel devices, not filesystems.
I understand the backward compatibility issue - but here comes a compromise
between backward compatibility and smart behavior.
If you stick to 'backward compatibility' at least provide an interface to the
sane behavior I suggest, like a configuration option in /etc/sysconfig or
anything similar, so the sane behavior can be used and supported, and doesn't
need to be a 'hack'.

If needed - I don't mind writing that additional feature and commiting it to
rawhide for future use. Perhaps that patch could maybe make it to RHEL4, 3, or both.
Comment 3 Karel Zak 2005-11-03 09:01:10 EST
Well, I think an option in /etc/sysconfig is a possible way. I will try to
prepare some experimental version of devlabel with this feature. Maybe we can
add it to some future update. 

Note, RHEL3 is last distribution with the devlabel command. There is not
devlabel in >=RHEL4.
Comment 5 RHEL Product and Program Management 2006-11-29 08:00:49 EST
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 

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