Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I am using LVM on Ubuntu 9.10 (Karmic). I have a single LVM physical volume (and a single volume group).

I have an ext3 filesystem inside an LVM logical volume which I no longer use, but for the time being I would like not to delete it. I'm trying to figure out how to minimise the space it takes up inside my PV. resize2fs has the -M option which works well at resizing the filesystem to have zero free space, but of course this doesn't affect the logical volume. Most of the recipes on the web for shrinking ext3 inside an LV (e.g. this one), follow this basic pattern to alleviate problems with inaccurate calculations of filesystem boundaries, etc.:

  • Shrink ext3 more than you quite want with resize2fs
  • Shrink the LV to the exact size you want
  • Re-run resize2fs to grow the filesystem slightly to efficiently use the complete LV.

That doesn't fully solve the problem in my case, because I want the LV size to be driven by the filesystem, rather than the other way round.

Is there a command or commands I can run to do this? Alternatively, it is possible for me to do the calculation of the filesystem size to give to lvresize with some degree of confidence?

share|improve this question

2 Answers 2

up vote 3 down vote accepted

In theory, yes, you can calculate the exact size of the LV required by the filesystem -- when resize2fs does it's thing, it'll print out how many blocks are in use. Unfortunately, getting it slightly wrong results in a broken filesystem, and wasting 100MB of space in exchange for not boning a filesystem is a tradeoff most people are willing to make.

EDIT: At the risk of giving a monkey a machine gun and hosing your filesystems for all time, the following process worked for me on a scratch filesystem:

  • fsck -f /dev/vg/sizetest
  • resize2fs -M /dev/vg/sizetest
  • Take the number of blocks (and the block size) from the "Resizing the filesystem" line of resize2fs, and calculate the number of kilobytes involved by multiplying the block count by the block size in kB:
    • "Resizing the filesystem on /dev/vg/sizetest to 119325 (4k) blocks" translates to 119325 * 4 => 477300 (important number for the next step)
  • lvresize -L477300k vg/sizetest
  • At this point, if your size isn't right, you are totally and utterly boned -- expanding the filesystem again won't necessarily get you the same blocks back in the same order.
  • fsck -f /dev/vg/sizetest
  • Remount the filesystem, note that df shows that the filesystem is 100% full, with 0 blocks available

If this bones your crucially important filesystem, don't tell me, for I shall merely engage in a lengthy "told you so" dance, and nobody wants to see me dance. Trust me on that.

share|improve this answer
Understood, your argument is sensible - although I guess there isn't even a well-understood guideline - you say "100MB" but I'm guessing there's no science behind that :) I guess I just find it odd that the tools can't/won't do this automagically (for example, resize2fs does do the right thing when growing the filesystem, and makes it as large as the LV. –  Andrew Ferrier Dec 22 '09 at 16:12
It's just the Unix philosophy, of one tool to do one job. LVM knows nothing of filesystems, and resize2fs knows nothing of LVM. –  womble Dec 23 '09 at 0:01
@womble, not quite accurate, I think - resize2fs does work out the size of the underlying block device when you have grown an LV. Unfortunately, lvresize has no way of doing the opposite (and I haven't even seen an accurate explanation anywhere of how I would determine the exact size of the FS). –  Andrew Ferrier Jan 1 '10 at 23:27
What's not accurate in my comment? (a) "LVM knows nothing of filesystems", (b) "resize2fs knows nothing of LVM", or (c) "the Unix philosophy, of one tool to do one job" ? –  womble Jan 1 '10 at 23:51
(c), a bit :) resize2fs does look at the size of the underlying LV. Admittedly, I assume it sees that as just a block device, so you could argue that it's still just one-tool-per-job, but the point is, there's a solid/safe solution in one direction (growing), and not the other (shrinking). Thanks for your edit, by the way. I think I don't need it enough that I'll risk it (!), but good to have it written down anyway. Thanks for your thoughts. –  Andrew Ferrier Jan 5 '10 at 20:57

It might not be the best solution, but this is what I would do:

  • copy the data to another volume
  • resize your volume (the way you described) to the desired size
  • put your data back

I hope someone has a better solution, but this one should at least work if no other does.

share|improve this answer
Hmm, maybe I haven't explained my problem clearly enough. I think that doesn't help me, because I still wouldn't know what size to set the logical volume too. –  Andrew Ferrier Dec 22 '09 at 11:15
How about running du -sh on your data first to determine how much space you need for your LV ? –  ℝaphink Dec 22 '09 at 11:49
Raphink, I don't think that will help. That won't include all kinds of FS overhead that du -sh won't count. Basically, it's not an accurate figure... –  Andrew Ferrier Dec 22 '09 at 16:13
Hmmmm, I see. Do you really need to keep it as a LV? If the data is static and you want to minize it, you could dump it to an iso image and mount it. –  ℝaphink Dec 22 '09 at 16:39
TarballFS to the rescue! (Caution: TarballFS may not exist in this reality) –  womble Dec 23 '09 at 0:02

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.