10

On my intranet server, I have a 100.00 GiB partition /dev/sda5, which I use as a physical volume for lvm2.

  • It's the only physical volume in my volume group vg01.
  • vg01 currently contains one logical volume lv01, using the full 100.00 GiB - well, actually 99.99 GiB due to some rounding (that's where the problem starts).
  • lv01 contains an ext3 file system, using the entire space.

I want to reduce lv01 to approximately 97 GiB, so I can create lv02 with approx. 3 GiB (I need it to take lvm snapshots).

What I did so far:

e2fsck -f /dev/mapper/vg01-lv01
resize2fs /dev/mapper/vg01-lv01 97G

This has worked well. But now I'll have to run

lvreduce --size ? /dev/mapper/vg01-lv01

And I'm not sure, which exact value I'll have to specify. The lvreduce man page warns explicitly, that the resulting size must not be smaller than the file system. I also don't want to make it larger than it has to be. But now I have different numbers:

  • I specified 97G in resize2fs.
  • df -h says, it's 96 G.
  • df says, it's 100115936 1K-blocks.
  • lvdisplay (of course) still reports 99.99 GiB for the logical volume.

What will I have to specify for lvreduce?

Edit:

The currently accepted answer provides a nice workaround. However, in order to integrate such things in solid scripts etc., I would generally prefer to use precise measurements instead. Or maybe there's already a reliable (!) script or tool which performs the entire resize procedure in one step?

Chris Lercher
  • 4,152
  • 9
  • 35
  • 41
  • 3
    You could use `resize2fs` to reduce the filesystem down to 90GiB or so, and then muck around with arguments to `lvreduce` (followed by `resize2fs`) to see what works best. – larsks Jul 08 '11 at 10:08
  • @larsks: Great idea (because resize2fs can adjust automatically to the partitions size, whereas lvreduce can't adjust automatically to the fs size). If nobody knows the definite answer to my question, I think this will be the solution. – Chris Lercher Jul 08 '11 at 10:19
  • Why don't just just pass the same size into lvreduce? Unless you make a typo lvm should recognise it is the same size, and not resize it again. And if you do make a typo, at least you avoided destroying your filesystem. lvreduce -r -L 97G /dev/mapper/vg01-lv01 – Bill Apr 11 '20 at 00:11

2 Answers2

14

I think this is best done using the --resizefs option to lvreduce/lvresize:

   -r, --resizefs
          Resize underlying filesystem together with the logical volume using fsadm(8).

Admittedly, that doesn't help you now, but it may in the future.

mjk
  • 273
  • 2
  • 6
  • That's what I was looking for! It seems to be a new option though: It's in version [2.02.74(2)-RHEL](http://unixhelp.ed.ac.uk/CGI/man-cgi?lvreduce+8) but it is missing in my version [2.02.66](http://manpages.ubuntu.com/manpages/natty/en/man8/lvreduce.8.html) of LVM tools. – Chris Lercher Jul 08 '11 at 13:57
  • 1
    When I had already resized the fs using other tools, this option suppressed the usual warning, and printed the message "The filesystem is already 3932160 blocks long. Nothing to do!" Just as desired. – Chiara Coetzee Oct 02 '13 at 05:35
  • Even in 2020, none of several tutorials about extending/shrinking lvm volumes proposed by Google on its first search results page mentions this option. Thanks a lot! – Ivan Shatsky Feb 20 '20 at 20:39
5

In my experience, LVM and resize2fs have the same ideas about what "97G" means, so specifying the same size in both places should be fine. However, I'm paranoid, and wherever possible always use the strategy suggested by larsks in the question comments and resized to be one GB smaller than I wanted, done the lvresize to the size I wanted, and then re-run resize2fs (without a size) to let it expand back out to fill the whole LV.

womble
  • 96,255
  • 29
  • 175
  • 230
  • I think, it's important to be "paranoid" here - because not only is there a possibility that the current files be damaged: If the file system is larger than the LV, I assume that it can play havoc with the following volumes at any time in the future. – Chris Lercher Jul 08 '11 at 13:16
  • No, LVM will prohibit any attempt to write beyond the end of the LV, so no other LVs can be damaged. If the filesystem is truncated, though, it does result in fairly catastrophic results. – womble Jul 08 '11 at 22:50
  • That's interesting - I didn't know that it checks every write! Good to know. – Chris Lercher Jul 09 '11 at 09:26