[linux-lvm] lvreduce nightmare
Bryn M. Reeves
bmr at redhat.com
Fri May 18 10:25:48 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
On 05/18/2012 12:13 AM, Ray Morris wrote:
> Stop. Don't do anything else until you are sure of what to do next.
> You will not lose data by studying. You can lose data by trying to
> fix it.
>> resize2fs /dev/vg0/data 100G lvreduce -L -100G -n /dev/vg0/data*
> A 100 GB filesystem needs a block device of around 110 GB. So
> this cut off the end of your filesystem. (The device needs to hold
> the journal as well as the FS, for example.)
Not with most file systems. When you ask resize2fs to make a file
system 100G it will make it (within rounding limits) 100G's worth of
blocks in length. This is the actual space required on the disk (i.e.
the argument is the size of the file system image not the maximum free
space within it).
# lvcreate -L 100M -n l0 tvg0
Logical volume "l0" created
# mke2fs -j /dev/tvg0/l0
mke2fs 1.41.9 (22-Aug-2009)
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
25688 inodes, 102400 blocks
102400 1024-byte blocks is exactly 100M (MiB to be pedantic).
Resize to 50M gives:
# resize2fs /dev/tvg0/l0 50M
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on /dev/tvg0/l0 to 51200 (1k) blocks.
The filesystem on /dev/tvg0/l0 is now 51200 blocks long.
51200 1024 byte blocks is exactly 50MiB.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the linux-lvm