1

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?

Andrew Ferrier
  • 864
  • 9
  • 21

2 Answers2

5

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.

womble
  • 95,029
  • 29
  • 173
  • 228
  • 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
  • 1
    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 00: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 01 '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 01 '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 05 '10 at 20:57
  • As you say, `resize2fs` is only looking at the size of a block device, which it needs to do it's job. And there is a perfectly fine and safe shrinking procedure -- shrink to smaller than you need, resize the LV to the size you want, then expand. Perfectly safe and functional. – womble Jan 05 '10 at 21:48
  • So, if you do screw up the lvresize (Say by resizing to 4G instead of 4T...) you might be able to recover. Try `vgcfgrestore /etc/lvm/archive/_.vg`. Then `vgchange -an ` followed by a `vgchange -ay`. If you're lucky, you'll be able to fsck the disk from there. No guarantees though. – David Hogue Aug 27 '13 at 05:59
-1

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.

raphink
  • 11,337
  • 6
  • 36
  • 47
  • 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
  • 1
    How about running `du -sh` on your data first to determine how much space you need for your LV ? – raphink 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. – raphink Dec 22 '09 at 16:39
  • 1
    TarballFS to the rescue! (Caution: TarballFS may not exist in this reality) – womble Dec 23 '09 at 00:02
  • Raphink, that's actually a really good idea. Pretty obvious now you say it :) I might try that... – Andrew Ferrier Dec 23 '09 at 10:30
  • At least, loop-mounting an iso will save you the trouble of using FUSE. – raphink Dec 23 '09 at 10:58