3 ms·
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 8g
by clipradiowallet 6y ago
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 https://opensource.com/business/16/9/linux-users-guide-lvm
edit to add: pv=physical volume, vg=volume group, lv=logical volume
- uniformlyrandom 6y agoI would not say this is an alternative, more like yet another tool in a shed: 1. Tunefs 2. spacer.8gb 3. lvm
- ttyprintk 6y agoAdded benefit of not waiting to backup and restore 8 GB.
- rubiquity 6y agoYes 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.
- jonhermansen 6y agoIf 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))
- labawi 6y agoLVM 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).