[YLUG] lvm mistake

[Roger Leigh]

On Sat, Dec 18, 2010 at 05:29:48PM +0000, Patrick Dupre wrote:
> I made a big mistake, think that lvm partitionning was working has
> gparted !
>
> In a couple of words
> I made a lvreduce -l+250 /dev/Vol0/part1
> then
> lvextend -l+250 /dev/Vol0/part2

There's nothing wrong with this in principle.  In practice, you need to
reduce the filesystem size /first/ before you shrink the volume.

> part1 had more than 250 extends free but fsck abort on /dev/Vol0/part1
> (but is OK on part2).
> Can I go back, ie. move back the 250 extends ?

Probably not.  Do you know exactly /which/ extents need adding back,
and did they get zeroed out or overwritten in the meantime?  If you
did a filesystem resize on part2, you're most likely stuck.

LVM keeps an archive of its state in /etc/lvm/backups.  It's possible
that you can revert to a prior state using this information.  You'll
need to check the documentation for this (vgcfgrestore). But, as I said
above, if you revert the extent allocation changes, you may well have
corruption of the actual filesystem blocks.  If you're lucky (and you
made no other changes not mentioned above) it /might/ work.

* Make a complete backup of the disc as an image with dd before doing
***anything*** ***else*** *
* Also backup the LVM data in /etc/lvm *
* Don't use lvextend again; you might not get the same extents reused *

Only then can you be sure you won't have irretrievable data loss if
things get further damaged.

If you do get it working, make sure it fscks cleanly.  I'd then backup
the files, completely delete and recreate the volume and restore the
files back onto it.  This is to make sure there's no silent corruption
of the filesystem structures which could lead to further problems
down the line.

> fsck tells:
> The filesystem size (according to the superblock) is 6144000 blocks
> The physical size of the device is 5632000 blocks
> Either the superblock or the partition table is likely to be corrupt!
> Abort<y>? yes

This is expected given what you have done.  There are two sizes:

1) the partition size (which translates to the block device size; see
   /proc/partitions)
2) the filesystem size

Since the filesystem has to fit on the partition, it can't be bigger
than the partition size.  If you increase the size, this is done by

1) increasing the partition size (with lvextend)
2) increasing the filesystem size to fit with e.g. resize2fs

Conversely, if you reduce the size, you need to reverse the order

1) decrease filesystem size (resize2fs)
2) decrease partition size (lvreduce)

Since you did this in the wrong order, you have basically chopped of
the end of the filesystem; those blocks no longer exist.  Hopefully
you can add them back by restoring the old configuration.


Regards,
Roger

-- 
  .''`.  Roger Leigh
 : :' :  Debian GNU/Linux             http://people.debian.org/~rleigh/
 `. `'   Printing on GNU/Linux?       http://gutenprint.sourceforge.net/
   `-    GPG Public Key: 0x25BFB848   Please GPG sign your mail.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://mailman.lug.org.uk/pipermail/york/attachments/20101219/491c3636/attachment.pgp>