On Thu, Nov 14, 2002 at 09:35:06AM -0600, Jonathan S. Polacheck wrote: > I posted the following to the ext2 help forum and got the included > response; > > By: jpolache ( Jon Polacheck ) > reasize2fs fails > 2002-11-13 13:23 > I have an lvm volume for my /usr filesystem on a Mandrake 8.1 server. I did > a > lvextend, and am now trying to resize the filesystem into the logical > volume. > > I went to runlevel 1, unmounted all my filesystems (umount -a) and ran > e2fsck on /dev/sys/usr. I got output indicating that the superblock size > was 793600 blocks and the "physical" size was 665600 blocks. > > e2fsck ended with the following; > > Error scanning inodes (336000): can't read next inode > > /dev/sys/usr: 13494/400000 files (1.2% non-contiguous), 578502/793600 > blocks This was the point in time were you better had stopped and asked for advice :( > > When I then run resize2fs, I get the following output; > > resize2fs: Can't read a block bitmap while trying to resize /dev/sys/usr. > The file system on /dev/sys/usr is now 665600 blocks long. Boom. As Ted said: your fs is now smaller and you lost data. You probably didn't run lvextend but lvreduce instead, which made the logical volume smaller that the actual filesystem (similar to configuring a partition conatinig an ext2 fs smaller). LVM1 contains the e2fsadm tool which prevents you form doing things like that. The lvreduce alone wouldn't have been the end of the day, because you still had the old configuration with the prevoius LV size and mapping in the LVM metadata archive. Deactivating the VG and restoring that state of the metadata would have cut it. Now that you run resize2fs and Ted (the ext2/resize2fs guru) can't help you, it is tape archive time :( > > Any suggestions? > > By: tytso ( Theodore Ts'o ) > RE: reasize2fs fails > 2002-11-14 07:28 > That's an LVM problem. e2fsck was very clear when it told you that device > was smaller than the size specified in the superblock. > > ...there was probably severe damage to the filesystem which was done, > because resize2fs attempted to shrink the filesystem down to 665600 from > the superblock size of 793600. But since LVM had apparently already gotten > the idea that the device was now smaller, any data that was stored in the > blocks between 665600 and 793600 has been lost. > > ...................................................................................... > > Any suggestions as to how I can proceed from here? > > > _______________________________________________ > linux-lvm mailing list > linux-lvm@sistina.com > http://lists.sistina.com/mailman/listinfo/linux-lvm > read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/ -- Regards, Heinz -- The LVM Guy -- *** Software bugs are stupid. Nevertheless it needs not so stupid people to solve them *** =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Heinz Mauelshagen Sistina Software Inc. Senior Consultant/Developer Am Sonnenhang 11 56242 Marienrachdorf Germany Mauelshagen@Sistina.com +49 2626 141200 FAX 924446 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- _______________________________________________ linux-lvm mailing list linux-lvm@sistina.com http://lists.sistina.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
