Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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?


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?

share|improve this question
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 8 '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 8 '11 at 10:19

2 Answers 2

up vote 3 down vote accepted

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.

share|improve this answer
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 8 '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 8 '11 at 22:50
That's interesting - I didn't know that it checks every write! Good to know. – Chris Lercher Jul 9 '11 at 9:26

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.

share|improve this answer
That's what I was looking for! It seems to be a new option though: It's in version 2.02.74(2)-RHEL but it is missing in my version 2.02.66 of LVM tools. – Chris Lercher Jul 8 '11 at 13:57
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. – D Coetzee Oct 2 '13 at 5:35

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.