Hacker News Reader

Comment by clipradiowallet | Hacker News Reader

An alternative approach here... make sure (all) your filesystems are on top of LVM. This reduces the steps needed to grow your free space. Whether you have a 8gb empty file laying around, or an 8gb block device to attach...LVM will happily take them both as pv's, add them to your vg's, and finally expand your lv's.

some reading if LVM is new and you want to know more: https://opensource.com/business/16/9/linux-users-guide-lvm

edit to add: pv=physical volume, vg=volume group, lv=logical volume

View on HN

I would not say this is an alternative, more like yet another tool in a shed:

  1. Tunefs
  2. spacer.8gb
  3. lvm

Added benefit of not waiting to backup and restore 8 GB.

If you are using LVM on all of your filesystems, it seems like a bad idea to use a file residing on LVM block device as another PV. And actually I'd be surprised if this was even allowed. Though maybe it is difficult to detect.

You'd effectively send all block changes through LVM twice (once through the file, then through the underlying block device(s))

LVM is just fancy orchestration for the device-mapper subsystem with some headers for setup information.

For block operations it's no different from manual setup of loop-mounted volumes, that also need to travel a couple of layers to hit the backing device.

Though there is an important caveat - LVM is more abstracted, making it easier to mistakenly map a drive onto itself, which may create a spectacular failure (haven't tried).

Yes LVM can help here. Another approach would be when you create the logical volume to intentionally under allocate. Perhaps only use 80-90% of the physical volume.

Reply on news.ycombinator.com