Bug 695299 - Anaconda limits the maximum LV size derived from the PE size artificially
Summary: Anaconda limits the maximum LV size derived from the PE size artificially
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: anaconda
Version: 5.6
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: David Lehman
QA Contact: Release Test Team
URL:
Whiteboard:
Depends On:
Blocks: 726828
TreeView+ depends on / blocked
 
Reported: 2011-04-11 11:00 UTC by Luca Villa
Modified: 2018-11-14 13:13 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 769287 (view as bug list)
Environment:
Last Closed: 2012-02-21 05:37:32 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0197 0 normal SHIPPED_LIVE anaconda bug fix and enhancement update 2012-02-20 14:54:06 UTC

Description Luca Villa 2011-04-11 11:00:42 UTC
Description of problem:
During installation of RHEL 5.6, when you try to create a LV greater then:

LVsize=PEsize*64 (where pe=PEsize in KB and LVsize is in MB)

anaconda prevents you from doing it by returning an error dialog:

Dialog title: "Not enough space"

Text: "The current requested size ( 71478.00 MB) is larger than maximum logical volume size ( 65536.00 MB). To increase this limit you can create more Physical Volumes from unpartitioned disk space and add them to this Volume Group."


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

anaconda-11.1.2.224-1

How reproducible:

always

Steps to Reproduce:

1. create a VG with PE size small enough
2. try to create a LV bigger than PEsize*64 MB
3. The error dialog appears
  
Actual results:

anaconda prevents to create a LV with more than 65535 PEs

Expected results:

You should be able to create a LV up to the system limit independently from the PE size

Additional info:

It looks that this function in file lvm.py is enforcing the limit:

def getMaxLVSize(pe):
    """Given a PE size in KB, returns maximum size (in MB) of a logical volume.
    pe - PE size in KB
    """
    return pe*64

While the same function in RHEL6 is rather different:

def getMaxLVSize():
    """ Return the maximum size (in MB) of a logical volume. """
    if iutil.getArch() in ("x86_64", "ppc64", "alpha", "ia64", "s390", "sparc"): #64bit architectures
        return (8*1024*1024*1024*1024) #Max is 8EiB (very large number..)
    else:
        return (16*1024*1024) #Max is 16TiB

Comment 1 Rob Dunne 2011-06-01 18:55:13 UTC
We have seen this artificial limitation when trying to create an ext4 filesystem directly on a 12T raid array as well. (It is not limited to LVM)

Comment 2 David Lehman 2011-07-27 21:49:06 UTC
(In reply to comment #1)
> We have seen this artificial limitation when trying to create an ext4
> filesystem directly on a 12T raid array as well. (It is not limited to LVM)

Exactly what is the limitation you have seen and what are the exact steps you took?

Comment 3 Rob Dunne 2011-08-01 15:57:15 UTC
ext3 and ext4 filesystems on Redhat 5.6+ should have a size limit of 16TB. 

However anaconda limits you to 8 TB.

We have a RAID 6 volume that is roughly 11TB in size. If we try to format the whole 11TB as an ext4 filesystem in a kickstart we get an error saying the requested size is too large, and that the limit is 8388608 MB.

This is what the lines look like in our KS file.
cciss/c1d0 is a 1GB boot volume
cciss/c1d1 is a 2.4 TB / and swap volume
cciss/c0d0 is a 11 TB /home volume

part /boot --fstype ext3 --size=100 --grow --ondisk=cciss/c1d0 --asprimary
part swap --size=32768 --ondisk=cciss/c1d1 --asprimary
part / --fstype ext3 --size=30000 --grow --ondisk=cciss/c1d1 --asprimary
part /home --fstype ext4 --size=1000 --grow --ondisk=cciss/c0d0 --asprimary

So what we did was create a updates.img file that had a patched fsset.py file.

Original fsset.py
class extFileSystem(FileSystemType):
    def __init__(self):
        FileSystemType.__init__(self)
        self.partedFileSystemType = None
        self.formattable = 1
        self.checked = 1
        self.linuxnativefs = 1
        self.maxSizeMB = 8 * 1024 * 1024
        self.packages = [ "e2fsprogs" ]

we modified
self.maxSizeMB = 8 * 1024 * 1024
   to
self.maxSizeMB = 16 * 1024 * 1024

Now we can use the full 11TB in one filesystem. (My point is that not only are LV sizes artificially limited, but filesystems are limited as well.)

Comment 4 RHEL Program Management 2011-08-05 12:30:49 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

Comment 5 David Lehman 2011-10-19 15:42:06 UTC
The current lv size limits are from lvm1. We just need to update them to the lvm2 limits, which are already in the newer branches.

Comment 7 Alexander Todorov 2011-12-20 12:50:32 UTC
Steps to reproduce (issue in comment #0):

Using a KVM guest (5.7) with a disk image of 7TB and a smaller disk:

1) Create standard /boot and swap partitions on a smaller disk. 
2) Make all of the space on big disk a PV
3) Create a VG with PEsize = 1MB
4) Create an LV for /. In the UI Size (MB) is 7340030 while Max size label is 65536 MB.
5) Click OK to create the LV. The error message from comment #1 appears.



Tested again on 5.8 snapshot #1:
4) Size (MB) is 7340030, Max size label is 7340030 MB
5) LV is accepted by anaconda
6) Partitioning is correctly written to disk. Installation completes
7) After reboot / is 6.8TB

Comment 8 Alexander Todorov 2011-12-20 13:01:30 UTC
(In reply to comment #1)
> We have seen this artificial limitation when trying to create an ext4
> filesystem directly on a 12T raid array as well. (It is not limited to LVM)

To reproduce I used a similar KVM setup like above this time with a 15TB disk image:

On 5.7:

1) Create standard /boot and swap partitions on a smaller disk.
2) On the large disk create a single ext3 partition and select to use all available space
3) Anaconda creates a partition of 8388604 MB and leaves a lot of free space on the disk


On 5.8:

3) Same result.

Comment 10 errata-xmlrpc 2012-02-21 05:37:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0197.html


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