Using kickstart on large disks

[Digimer]

On 10-02-25 04:09 PM, Shabazian, Chip wrote:
> Why not just create the /db volume in the %post?
>
> -----Original Message-----
> From: kickstart-list-bounces at redhat.com
> [mailto:kickstart-list-bounces at redhat.com] On Behalf Of Arun
> Sent: Thursday, February 25, 2010 12:32 PM
> To: kickstart-list at redhat.com
> Subject: Using kickstart on large disks
>
> Hi -
>
> I was wondering if you guys had some thoughts on an issue I'm running
> into using kickstart to automate installs on intel x86 servers with
> large disks (~16 TB).
>
> What I'm trying to achieve is simple: a root volume of 100GB, and a
> database volume on all remaining space.
> It appears however that anaconda is restricting logical volumes to 8TB,
> even for ext4 partitions.
>
> I narrowed the problematic code down to storage/formats/fs.py where the
> Ext4 file type extends via Ext3 from Ext2, in which I saw this line:
> _maxSize = 8 * 1024 * 1024
>
> Is there a reason for this limit to be inherited down to Ext4 partitions
> as well? See my kickstart snippet below - the "/db" partition has the
> --grow option, but it will not grow beyond 8TB due to the code above,
> leaving nearly 8TB completely unused on the server.
>
> ------------------------------------------------------------------------
> clearpart --all
> bootloader --location=mbr
>
> # Create partitions: 200 MB for boot, remaining for everything else.
> part /boot --size=200 --fstype ext3
> part pv.01 --size=1 --grow
>
> # Create a single volume group
> volgroup vg pv.01
>
> # Create a swap volume of "recommended size", a root volume of 100GB
> # and a database volume on the remaining space
> logvol swap   --fstype swap --name=swap_vol  --vgname=vg --recommended
> logvol /      --fstype ext4 --name=root_vol  --vgname=vg --size=100000
> logvol /db    --fstype ext4 --name=db_vol    --vgname=vg --size=1 --grow
> ------------------------------------------------------------------------
>
> Thanks in advance,
> Arun

That would be a work-around to Arun's problem without addressing the 
underlying issue. With single drives being 2TB now, it's an issue that 
deserves direct attention, I would think.

Digi