I’ve written recently on how to handle systems with very large storage subsystems. One would think that as we make our way through 2009 that the supporting tools for such large filesystems are at the top of their game, but as I’ve been playing with 24TB of storage I’ve realised that this is hardly the case:
- The most commonly used bootloader for Linux systems, GRUB, doesn’t yet have capabilities to boot from GPT partitions (at least not in the stable release)
- The most commonly used partitioner, fdisk, doesn’t support GPT-partitioned disks (and hence no disk larger than 2TB)
- GNU parted, which does support GPT, insists on performing all partition resize operations itself (including resizing the contained filesystem). Since it doesn’t yet understand LVM, it can’t resize any partition that contains an LVM PV.
Today I ran into what appears to be a bug in the CentOS 5.3 installation partitioner, which left my 12TB RAID volume only partitioned to 8TB when I had supplied the –grow parameter in the Kickstart script. Since parted can’t resize LVM partitions, and there don’t appear to be any other tools out there at the moment for GPT partitioning on Linux, I’m left in a less than ideal position.
GNU parted can’t resize the partition because it can’t understand LVM. Fortunately I can just use it to create another partition with the remaining space and add it to the existing LVM volume group but this is really just a hack, and one that disturbs my obsessive-compulsive sysadmin nature. Were it not for the flexibility of LVM, we would be in a bit of a mess.
Sadly, it seems the large filesystem support that will soon become essential for everyone is largely lacking in adequate support.