Bug 116289 - BLKPG_ADD_PARTITION op of BLKPG ioctl doesn't let you add partitions >= 1TB
BLKPG_ADD_PARTITION op of BLKPG ioctl doesn't let you add partitions >= 1TB
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Peter Martuccelli
:
: 121462 121710 122445 123094 (view as bug list)
Depends On:
Blocks: 103541 116286 121609 132991
  Show dependency treegraph
 
Reported: 2004-02-19 14:14 EST by Robin Battey
Modified: 2007-11-30 17:07 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-18 09:27:19 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
patch to fix TB limit for BLKPG_ADD_PARTITION ioctl in 2.4 kernels (400 bytes, text/plain)
2004-02-19 14:41 EST, Robin Battey
no flags Details

  None (edit)
Description Robin Battey 2004-02-19 14:14:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 
7.23  [en]

Description of problem:
When using parted to create any partition of size greater than or 
equal to 1TB, I get an error message stating that there was an error 
informing the kernel about the changes.  After stepping through the 
process with gdb, I can see that parted is not the faulty one here, 
as it's passing the correct values to the kernel, using the 
BLKPG_ADD_PARTITION op of the BLKPG ioctl.

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


How reproducible:
Always

Steps to Reproduce:
1. find a terabyte server to play with (this is the hardest part)
2. run "parted /dev/sda mkpart primary 0 1048576"
3. watch the fireworks
    

Actual Results:  "Error informing kernal about changes made to 
/dev/sda. ..."
The partition is written to disk, but the kernel doesn't know about 
it until a reboot.

Expected Results:  No error message, and the partition to be 
available immediately.

Additional info:

This is especially debilitating when installing RHEL (or anything 
that uses anaconda) on a terabyte server.  If I create any partitions 
over 1TB, the install crashes.  The workaround I've been using is to 
not create the partition during the install, and use fdisk 
afterwards.
Comment 1 Arjan van de Ven 2004-02-19 14:19:33 EST
RHEL3 is limited to 1Tb for other reasons anyway (with the exception
of some select and specially tested and certified setups, which
includes the software used to access it)
Comment 2 Robin Battey 2004-02-19 14:41:18 EST
Created attachment 97838 [details]
patch to fix TB limit for BLKPG_ADD_PARTITION ioctl in 2.4 kernels

Looking at drivers/block/blkpg.c:66, at the add_partition function, I notice
that it stuffs the sector count from ppstart and pplength, signed long longs
(which are correct), to a pstart and plength, signed longs, giving it a limit
of 1TB (2^31 * 512).  Looking at include/linux/genhd.h:45, at struct partition,
is should be using an unsigned long, which gives the correct limit of 2TB (2^32
* 512).  The check for equality between the long long and the long is what's
causing the false negatives.  I've verified that changing pstart and plength to
unsigned longs fixes the issue, and I've attached the patch.  This problem/fix
are not restricted to RHEL, so I've made the diff against the standard kernel
source, as to be more universal.  The same issue is in the 2.6 kernels.
Comment 3 Ken Loeffler 2004-02-23 17:05:44 EST
I have gotten the same errors as was originally reported
but I am trying to reinstall and I am not trying to create
any partitions even near 1TB. The system does however
have +1TB partitions on disks other than the system disk.
I want to leave these partitions completely alone. Would
the bug and fix apply to this situation. Please advise.
Comment 4 Jeremy Katz 2004-04-21 17:08:39 EDT
*** Bug 121462 has been marked as a duplicate of this bug. ***
Comment 5 Jeremy Katz 2004-04-27 21:46:49 EDT
*** Bug 121710 has been marked as a duplicate of this bug. ***
Comment 7 Jeremy Katz 2004-05-12 15:52:14 EDT
*** Bug 123094 has been marked as a duplicate of this bug. ***
Comment 8 Jeremy Katz 2004-06-09 17:45:59 EDT
*** Bug 122445 has been marked as a duplicate of this bug. ***
Comment 12 Ernie Petrides 2004-07-12 11:45:27 EDT
This will be fixed in RHEL4.
Comment 13 Alan Cox 2004-08-16 10:16:55 EDT
Reopened for RHEL3 update issue
Comment 15 Peter Martuccelli 2004-09-28 17:13:51 EDT
Tested patch, parted still reported invalid information.  Additional
investigation required.
Comment 16 Robin Battey 2004-09-28 17:49:17 EDT
I ran into this as well.  Make sure to dd over the MBR with zeros, 
then run parted to create the new label ("parted /dev/device mklabel 
msdos"), and then try to run parted.  If I tried this without first 
blanking the MBR after attempting with the broken SYSCTL, I received 
an error message.
Comment 17 Peter Martuccelli 2004-10-12 17:19:32 EDT
Added parted Bugzilla entry #135468.
Comment 18 Jefferson Ogata 2005-01-09 00:52:20 EST
Meanwhile, how do those of us trying to use RHEL3 install on systems
with existing 4TB or larger filesystems? I just spent 3 hours trying
to install RHEL 3AS update 4 on a system with multiple 1.4TB
filesystems, to no avail.

This is a serious problem. Why hasn't it been addressed? Are we not
supposed expected install RHEL 3AS on file servers?
Comment 19 Jeremy Katz 2005-01-13 16:58:00 EST
*** Bug 144990 has been marked as a duplicate of this bug. ***
Comment 21 Ernie Petrides 2005-02-22 04:34:40 EST
A fix for this problem has just been committed to the RHEL3 U5
patch pool this evening (in kernel version 2.4.21-27.17.EL).
Comment 22 Tim Powers 2005-05-18 09:27:19 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-294.html
Comment 23 Michael Heiming 2005-05-19 16:20:31 EDT
(In reply to comment #22)
> An advisory has been issued which should help the problem
> described in this bug report. This report is therefore being
> closed with a resolution of ERRATA. For more information
> on the solution and/or where to find the updated files,
> please follow the link below. You may reopen this bug report
> if the solution does not work for you.
> 
> http://rhn.redhat.com/errata/RHSA-2005-294.html

Argh, was under the impression the recent kernel update would allow to lift the
2TB limit, which isn't an issue using jfs. IIRC ext3 is limited to 1.3TB on RHEL
3, even if you can create a 2TB fs, be warned it takes ages.

Allowing larger blockdevices (16TB should be fine) and more SCSI sg* devices
then only 256 would be most welcome!

Comment 24 Ernie Petrides 2005-05-19 17:59:33 EDT
Michael, the 2-TB limit will never be raised in RHEL3 because of kABI
restrictions.  I believe RHEL4 does not have this limit.
Comment 25 Michael Heiming 2005-05-19 19:34:21 EDT
Enrie, yep you are quite right, after looking a bit more about the issue, it
doesn't work out on kernel 2.4, already test installed 4.0. Good job, my 3.0 .ks
files worked with very little modifycation.;)

But alas, I'll go nowhere with 4.0, until it's in this .pdf under
server+client+tape drives:

ftp://ftp.legato.com/legato/scg/legato_scg.pdf

In addition, still grievously missing an online extendable FS in the supported
kernel. IIRC there was a project to add online resize to ext3, sounded promising
from the mailing-list, but never found the time to test it out. Jfs seems to
have improved greatly in RHEL 3 unsupported package.

BTW
Glad to read you extended RHEL 3 support until 2010.;)

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