LVreduce error HELP!!!!

[James Murtagh]

Hi Babs,

I haven't had a chance to read all the notes but if your lvol is still showing as 2GB just lvextend it back to the original size. If you did have little free space before hopefully this should just use the same extents. By using lvreduce even without reducing the filesytem first the data should still be there.

Regards,

James.

[John Palmer]

If it's still only 2Gb then it's likely that the vg00.conf.old that you recovered from was written after you did the lvreduce. Did you check the dates of the files?

It's possible that you have a vg00.conf file on a backup tape that could be used to try again but it depends on what other LVM changes you've made.

Also, if you think that the volume was contiguous then you could simply try lvextending it to its original size and then try fsck again.

Sorry if we've failed you. Hope you've got good backups and that you've learned from the experience, I'm sure a lot of others have ;-)

Regards,
John

[James Murtagh]

Hi again Babs,

I've just recreated your issue to show you the process. I created a 10 extent lvol in vg00, polpulated it, reduced it and extended it again.

# bdf /itrc
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol12 40960 38868 2004 95% /itrc
# umount /itrc
# lvreduce -l 5 /dev/vg00/lvol12
Warning: The Logical Volume has a file system larger than the reduced size.
Reducing the Logical Volume will cause filesystem corruption.
When a logical volume is reduced useful data might get lost;
do you really want the command to proceed (y/n) : y
Logical volume "/dev/vg00/lvol12" has been successfully reduced.
Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf
# lvextend -l 10 /dev/vg00/lvol12
Logical volume "/dev/vg00/lvol12" has been successfully extended.
Volume Group configuration for /dev/vg00 has been saved in /etc/lvmconf/vg00.conf
# mount /dev/vg00/lvol12 /itrc
# bdf /itrc
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol12 40960 38868 2004 95% /itrc

The only issues you mave have is the allocation policy or distribution of the lvol but you should be able to get the data back.

Regards,

James.

[Babs_1]

Hi James,
tried that before posting about the issue, just tried it again there just to check, the lvol is not mounted and it says that the lvol in question is not in the root inode whatever that means?
I have more or less accepted (*sniff*) that its screwed...

[James Murtagh]

Hi Babs,

As John has mentioned, it looks like the vgcfgrestore failed to bring back the lvol. This is normally due to a cron job overwriting the old version during routine vgcfgbackup's. One option would be to restore the /etc/lvmconf/vg00.conf from before you did the work (if you do restore it to vg00.restore or something similar) and try to restore the config again.

If you don't have a backup of this if you could attach the output of "vgdisplay -v vg00" and "lvdisplay -v /dev/vg00/lvol10|head -40" we might be able to determine the command used to extend it in the correct order.

Regards,

James.

[Babs_1]

Your not going to believe this but, I tried an lvextend and its gone back to its previous size of 13gb, however I tried to run fsck and got this back
# fsck -F vxfs -o full /dev/vg00/rlvol10
vxfs fsck: file system had I/O error(s) on meta-data.
log replay in progress
fileset 1 primary inode 10 has invalid size (3334144)
fileset 1 primary inode 10 has invalid number of blocks (3264)
fileset 1 primary inode 10 has invalid block map
fileset 1 primary inode 42 has invalid size (3334144)
fileset 1 primary inode 42 has invalid number of blocks (3264)
fileset 1 primary inode 42 has invalid block map
vxfs fsck: No valid EMAP inodes found
vxfs fsck: cannot re-initialize aggregate after replay
file system check failure, aborting ...

I cant mount the volume group buts size is showing up as 13gb with lvdisplay and also in SAM

Thanks again to John and everyone else, I sure have learned a lot this afternoon! this list is great!
Worst case scenario is I have to restore the data now....so watch out for my next post.....Arcserve restore to Unix lvol HELP!!
(hopefully not!!!)

[James Murtagh]

Hi Babs,

I think the posts are being overlapped and you may be well on the way to recovery now but...

Created a vxfs version 3 filesystem (I assume you are using this at 11.00) and checked those inodes - these are the extent maps so I would imagine the lvextend didn't create the extents as they were before.

I would suggest you restore the vg00.conf from yesterday and retry the vgcfgrestore then the fsck again, I am sure this would work. I have seen a lot worse than this recovered, and you haven't really done anything that would affect the data.

In any event, good luck!

Regards,

James.

[James R. Ferguson]

Hi (again) Babs:

In an effort to preserve the state of your '/etc/lvmconf/vg*.conf/' files, remember that every LVM command automatically runs 'vgcfgbackup' by default. Thus, a new copy of '/etc/lvmconf/vgNN.conf' is created and the predecessor configuration file renamed '/etc/lvmconf/vgNN.conf.old'. You can always copy and retain a '.conf' file as another name (as you have seen from the 'vgcfgrestore' man pages). Otherwise, should you ever wish *not* to automatically create a new '.conf' file, every LVM command has an '-A y|n' option to create or not perform the autobackup. This is useful to remember.

Regards!

...JRF...