LVM Resize - After logical resize, FS size does not match physical size.
 

Hi all,

I am new to the site but have reasonable experience with Linux but certainly wouldn't call myself an expert!

I don't however have any previous experience with LVM prior to this install.

I'll give everyone a quick "heads up" on my system / LVM config.

The system is a Dell PE1850 with 1 Seagate Cheetah SCSI Disk, it is controlled by a LSI Logic (MPT Fusion in the Kernel) RAID controller, however currently it is not in RAID.

I am running the Debian (Etch) distro, Kernel 2.6.18.1 and have created a logical volume group called "Debian"

My fstab reads the following:

/dev/mapper/Debian-root 481M 248M 208M /
/dev/mapper/Debian-tmp <sizes> /tmp
/dev/mapper/Debian-usr <sizes> /usr

and so on with a logical volume for usr, tmp and var directories.

I went through the LVM volume resize as desribed here.

I unmounted my / volume and my /home volumes, and due to the large space I had on /home, used lvreduce -L to reduce the size by 10G. I then used lvextend and resize2fs and rebooted.

Afterwards my system would not boot (due to errors on dm4) however it allowed recovery console) and if I run fsck or e2fsck it claims that the filesystem size (according to superblock) is different to the physical size of the drive.

e2fsck confirms all logical volumes are fine except the /home directory. However I can still access the /home directory and its contents (but it doesn't matter if these have to be destroyed)

I have now taken the /home mounting out of the fstab which boots the system np. However the problem still remains.

Anyone have any idea's how to fix this or what I did wrong to cause the error? Any help is appreciated!

Cheers,

Dave

Before using lvreduce on /home, did you also run resize2fs on it?

No :o

Have I commited an atrocity?

Do you know how to resolve?

Certainly ;-)

To reduce: first reduce the file system, then the underlying logical volume
To extend: first extend the underlying logical volume, then the file system

Now your /home file system believes it still has its initial size, while the underlying LV has been reduced.

Try to unmount /home, run resize2fs and e2fsck on it, and with a little bit of luck you'll be fine. Assuming /home is ext3, of course.

Thanks for the help uselpa.

If I run resize2fs the system returns:

sol:~# resize2fs -f /dev/Debian/home
resize2fs 1.39 (29-May-2006)
Resizing the filesystem on /dev/Debian/home to 24992768 (4k) blocks.
resize2fs: Can't read an block bitmap while trying to resize /dev/Debian/home

If I run e2fsck, it returns:

sol:~# e2fsck -f /dev/Debian/home
e2fsck 1.39 (29-May-2006)
The filesystem size (according to the superblock) is 27614208 blocks
The physical size of the device is 24992768 blocks
Either the superblock or the partition table is likely to be corrupt!

I dont mind if I have to destroy the entire partition and create it again if its going to be easier, there are no files I want to keep.

To avoid any further filesystem related devastation, i'll await your best call on the subject ;)

All a good learning curve though, good that the beasts aren't in a data centre yet otherwise it would have been a case of shit and fan :p

If you don't mind losing the data, then recreate a file system on the LV and remount it to /home. If you have any other users besides root, I'd suggest removing and recreating them so that their home directories are properly created.

There's probably a way to correct the situation but I don't know it, and as it's not strictly necessary let's leave it at that.

And repeat the mantra: RFL, ELF (reduce filesystem then LV, extend LV then filesystem) ;-)

Great mate I did just that, and added the additional require space to / hassle free.

All spot on now! Most appreciated cheers!