Sunday, June 28, 2009

Linux LVM

I decided to abandon /home as an NFS mount. It worked OK but the performance affected Firefox which writes a lot of files to its cache. I also had edge cases like this one. But before moving /home back to a local drive, I needed to rearrange the space. I have enough disk space but it is not divided up efficiently. These days I use the Linux Logical Volume Manager (LVM) which makes shuffling disk space more convenient than direct partitioning of the drive. However, the risks are the same so backups are essential.

I've only shrunk/extended LVs once before so it was the first test of my notes. When doing this type of work, you are either in single user mode or running from a rescue CD, so your access to the Internet is not always dependable. With this in mind I checked the notes against known good references before starting. The LV resizing looks like this:
$ umount /var
$ e2fsck -f /dev/mapper/vg0-lv1
$ resize2fs /dev/mapper/vg0-lv1 1048576K
$ lvreduce -L 1048576K /dev/mapper/vg0-lv1
$ e2fsck -f /dev/mapper/vg0-lv1
$ mount /var
$ lvm pvdisplay
...
Total PE 1024
...
$ lvextend -l +1024 /dev/mapper/vg0-lv2
$ resize2fs /dev/mapper/vg0-lv2
$ e2fsck -f /dev/mapper/vg0-lv2
$ mount /dev/mapper/vg0-lv2 /home
I omitted some details here which were specific to the system. For example Debian starts a few daemons in single user mode, which I had to stop those before I could unmount /var. A rescue CD wouldn't have that problem.

I made one mistake which fortunately I caught in time. I left out the "K" on the end of this command:
$ resize2fs /dev/mapper/vg0-lv1 1048576K
That resulted in the file system being 4GB (1048576 4KB blocks) instead of the 1GB I had intended. Fortunately, I caught the error before reducing the LV which then would have truncated the file system. As I said before, the risks remain the same.

No comments:

Post a Comment