Bug 161567 - parted/libparted recognizes only 128 scsi disks
parted/libparted recognizes only 128 scsi disks
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: parted (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: David Cantrell
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-06-24 11:10 EDT by Lee Schermerhorn
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version: parted-1.6.19-4.EL
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-09-13 14:28:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Lee Schermerhorn 2005-06-24 11:10:27 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4

Description of problem:
libparted [linux.c:_device_probe_type()] recognizes scsi disks via the device major number.  linux.c contains a copy of scsi disk major # definitions lifted from some antique version of <linux/majors.h>.  As a result, any scsi disk with a major # in SCSI_DISKi_MAJOR, for i=8..15 will not be recognized as a scsi disk.

Symptoms:  when labeling/partitioning a disk with one of the unrecognized major numbers, parted/partprobe will not commit the changes to the os.  No kobj will be registered, no hotplug events will be generated, no device special files will be created.  Thus, it is necessary to reboot the system to see partitions on any disk after the first 128 scsi disks discovered.  [Booting a system with > 128 disks can be painful :-(].

Adding SCSI_DISKi_MAJOR, i=8..15 and updating the SCSI_BLK_MAJOR macro to check for the additional majors allows parted/partprobe to support up to 256 disks.  Not a very satisfying solution as the sd* namespace supports ~18000 disks.

Version-Release number of selected component (if applicable):
parted-1.6.19

How reproducible:
Always

Steps to Reproduce:
1. boot a configuration with >128 scsi disks
2. use parted to label a disk with major # >= 128 [SCSI_DISK8_MAJOR]--e.g., sddy is the first one to fail.  
3. Note that no /sys/block/sddy/sddyN files are created and no /dev/sddyN device special files are created.  You can also instrument /sbin/hotplug [e.g., 
  

Actual Results:  Note that no /sys/block/sddy/sddyN files are created and no /dev/sddyN device special files are created.  You can also instrument /sbin/hotplug [e.g., add a script to /etc/hotplug.d/default to log the ACTION, SEQNUM, DEVPATH environment variables to syslog] to see that no hotplug events are generated for disks >= sddy.  Reboot and the /sys/block/... entry and the /dev dsf will appear.



Expected Results:  parted should have issued BLKPG/BLKPG_ADD_PARTITION ioctl() to update the kernel's knowledge of the new partition[s].  This will cause a kobj to be registered [/sys/block/... entry] and a hotplug event to be generated [for udev to consume].  /sys/block/... entry and /dev/... dsf should be created w/o reboot.

Additional info:

Similar 128 disk limits exist in other tools [e.g., sg-utils]--apparently hold overs from 2.4.x.  I will enter a separate boog for each of these that I encounter.  However, this does suggest the need for a more robust method of determining device types, limits on same.
Comment 1 David Cantrell 2006-09-13 14:28:46 EDT
This problem was addressed in the parted update included with the RHEL4 U4
quarterly update.  The notice is:

RHBA-2006:0384 - parted bug fix update

And the parted package version and release is:

parted-1.6.19-4.EL

If you have an RHN account, you can view the advisory here:

https://rhn.redhat.com/rhn/errata/details/Details.do?eid=4542

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