Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 155728 - Support and limitations of >2TB devices needs to be spelled out
Summary: Support and limitations of >2TB devices needs to be spelled out
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: Installation_Guide
Version: 4.7
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Jack Reed
QA Contact: ecs-bugs
Depends On:
TreeView+ depends on / blocked
Reported: 2005-04-22 16:01 UTC by Joshua Baker-LePain
Modified: 2013-06-17 05:27 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2012-06-20 16:13:24 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Joshua Baker-LePain 2005-04-22 16:01:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

Description of problem:
I experienced a great deal of frustration recently trying to install RHEL4 on a large file server.  Initially, the system had 2 3ware 9500-12 cards in it, each presenting the OS with a 3TB disk.  The only reference to large filesystems I found anywhere in the documentation was that RHEL4 supports 8TB ext3 filesystems.  Over the course of the installation, I discovered:

a) One must use gpt disk labels on >2TB disk devices

b) It is, therefore, impossible to boot from a >2TB disk device, as neither grub nor LILO supports gpt disk labels.

c) One must use parted to partitions >2TB disk devices, as it is the only partitioning tool with support for them.

d) One cannot use the supplied mdadm to assemble an array with >2TB members, as the version shipped with RHEL4 does not support such big devices (this is already fixed upstream).

I'm sure there are many other gotchas in this sort of configuration, but those are the ones I ran into.  I really think these things need to be explicitly documented, given that the 8TB filesystem support is touted pretty much as soon as one starts looking into RHEL4's features.  The release notes may be more appropriate than the install guide, but I couldn't find a bugzilla entry for them.

Version-Release number of selected component (if applicable):
rhel-ig-x8664(EN)-4-HTML-RHI (2004-09-24T13:10)

How reproducible:

Steps to Reproduce:
1. Read supplied documents.
2. Try to work with big disk devices.
3. Experience much frustration.

Additional info:

Comment 1 moylo 2005-04-26 08:49:20 UTC
Will this be fixed in U1?

Comment 2 Karl Grindley 2006-10-23 14:19:26 UTC
Still not fixed in U4.  An update would be apreciated.

Comment 4 Rajdeep Sengupta 2006-11-30 08:26:45 UTC
I waiting for any fix on this. I have expereinced the same issue recently with 
RHEL 4 U4.

Comment 5 Rajdeep Sengupta 2006-11-30 08:27:26 UTC
I waiting for any fix on this. I have experienced the same issue recently with 
RHEL 4 U4.

Comment 6 Hans-Helmar Althaus 2007-01-21 11:29:19 UTC
(In reply to comment #5)
> I waiting for any fix on this. I have experienced the same issue recently with 
> RHEL 4 U4.

I am also waiting for a solution. The biggest problem seams that it is not
possible to boot from a drive bigger than 2TB !! I have such machines and
i do want to use Linux.

Comment 8 Colin.Simpson 2007-05-28 18:49:46 UTC
I'm also wating for this to be fixed. I have now got several Dell Poweredge
systems where I can happily configure 5 x 750GB SATA disks onto the PERC Raid
controller in RAID 5. The installer happily lets me partition the disk into a
small /boot and the rest into an LVM and then add my partitions onto the LVM.
The install goes through clean and then fails to boot on first reboot.

My only work around is to stick 3 disks into a RAID 5 and 2 into a RAID 1. Stick
the /boot on the RAID 1, LVM the rest of the RAID 1 and the RAID 5 together.
Very messy and wasteful on disk space. But I can't think of anything better to
do, the PERC only works at the whole drive level not partitions. 

Surely this should be documented in the release notes, (for the record this
isn't in the Dell Red Hat release notes/install guide either). Or the installer
should warn and refuse I'd have thought. Do lots of people not see this?

And this isn't fixed in RHEL 5 either.... Grub2 does supposedly support booting
from GPT partitions but this doesn't ship with RHEL5 (does the installer even
create them?).

Comment 9 Michael Hideo 2007-10-23 02:49:05 UTC
Removing automation notification

Comment 10 Michael Hideo 2008-01-22 04:36:24 UTC
Moving to Don

Comment 11 C.M. Connelly 2008-09-25 23:56:08 UTC
Also a problem in RHEL 5.

Comment 12 Eric Smith 2010-11-11 19:37:22 UTC
There are still problems in Fedora 14, so I'm guessing that this probably isn't fixed in RHEL 6 either.  The Fedora 14 installer recognizes my 7 TB RAID and shows that 7 TB is available, but won't let me create an LVM physical volume  larger than 2TB.  If I try to create two physical volumes on the same RAID, it won't let them be more than 2 TB total.

Comment 13 Eric Smith 2011-04-14 01:07:55 UTC
Verified that RHEL 6 Anaconda won't let me put a GPT on a drive (using 3ware hardware RAID), and won't let me create an LVM physical volume larger than 2TB.

Given that 3TB drives are now cheap, and that hardware RAID volumes can easily exceed 2TB even when using smaller drives, it really seems like it would be a good idea for RHEL to support it.

Note that I do not necessarily need the ability to boot from a >2TB and/or GPT device, though that would be nice.  3ware (and perhaps other?) hardware RAID cards allow carving a smaller volume out specifically to deal with software that can't boot from a >2TB or GPT volume.

Comment 14 Eric Smith 2011-04-15 21:32:42 UTC
Created a GPT on the RAID volume, and started RHEL 6 installation over.  Anaconda is then willing to create >2TB PVs on the GPT volume.

Comment 15 Konstantin Volkov 2012-04-28 08:12:03 UTC
The next patch fixes the bestDiskLabelType selection and allow to use gpt instead of mbr on >2TB block devices:

--- anaconda-13.21.149.orig/>2011-11-04 19:53:03.000000000 +0400
+++ anaconda-13.21.149/<---->2012-04-28 11:36:30.716757626 +0400
@@ -166,7 +166,7 @@
             labelType = self.defaultDiskLabelType
             for lt in self.diskLabelTypes:
                 l = parted.freshDisk(device=device.partedDevice, ty=lt)
-                if l.maxPartitionStartSector < device.partedDevice.length:
+                if l.maxPartitionStartSector > device.partedDevice.length:
                     labelType = lt

Please, apply.

Comment 16 Jiri Pallich 2012-06-20 16:13:24 UTC
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

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