Resizing Your File System: There’s A Pill For That 3

Funny how 3 preceded two… well, the story is simple. I had a Centos machine that needed

more storage. The problem is that the setup is what I liked to call a babushka doll setup. It’s pretty straight forward. The Centos install in on an ext3 partition, on an LVM partition, provided by Xen, mounted over NFS. We have to work backwards here to make this work. As a note, my method to resize the LVM device will not work if it is not the last partition on the partition table. If it is, then you may have to settle for creating another physical volume, then adding it to your logical volume and extending your LVM on to that.

Now I tagged this online, but I had to reboot twice. If you remove the Xen part of this, then it probably would be. Xen is using a file backed block device, so the first thing to do is extend this image by however many gigabytes we need. In my case we needed at least 10 more gigabytes. Here is the code how to do this.

dd if=/dev/zero of=centos.img oflag=append conv=notrunc count=$[1024*10] bs=$[1024*1024]

I am doing some math here. The bytes at a time is set to 1024 to the power of 2, which gives us a megabyte. Then I count 10 x 1024 megabytes. The over all is 10 gigabytes will be appended to centos.img. I set notrunc as a precaution not to erase my existing file. Please be careful using these commands. Without append and notrunc you will erase your data. In fact, if space permitted, always backup your block device. Now, I can’t do that because I never have the time or space.

Sadly, the centos.img file is an entire block device. It has partitions and I didn’t know what geometry of the virtual disk to go ahead and change it. This is where I had to reboot my virtual instance to get it to reread its partition table. It may be possible to use parted’s partprobe to reread this. I haven’t tested it. If it does work, then this reboot may be avoided.

The scariest part of all of this is that you now need to delete your LVM partition and recreate it at the same starting block. Notice below that both starting blocks are 14? The end block will now be the

last block on the device. Because I was unable to boot to another machine or a live cd to accomplish this, I am booted to the machine I am resizing. Also because this is my root file system, the kernel will be unable to reread the

partition table as the device is mounted and busy. This is where my second and last reboot takes place. If this was not a mounted file system or you created an alternative root file system to pivot_root to, then you may be able to avoid this. If this is your root and you wanted to pivot_root, I would ask yourself why bother.