[ale] to lvm or not lvm is my dillema
DJPfulio at jdpfu.com
DJPfulio at jdpfu.com
Fri Jan 2 11:03:05 EST 2026
Yesterday, I ran out of storage in an LV used for containers. A few refused to start after I shut them down to start troubleshooting. Nothing in the logs for any of the containers at startup. Finally, I got some debug information and saw "Out of space" error.
5 seconds later and I'd added 10G more to the LV and all the containers started with no issues.
# lvextend -L+10G /path/to/lv-device
That's easy, provided the VG has unused storage. Never allocate all the storage in a VG completely. For example
$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
vg01 1 9 0 wz--n- <930.78g <644.68g
The running containers using the same LV storage kept working the entire time. I'll reboot the system sometime this weekend, just to be certain all is well with the added LV storage.
IF you have LVM and have never used pvmove, you are in for treat when it is time to move to a larger HDD/SSD. 1 command, leave it running overnight regardless of whatever else is happening. In the morning, the entire PV is on the new storage. Beautiful thing.
On 1/2/26 10:06, Solomon Peachy via Ale wrote:
> On Thu, Jan 01, 2026 at 05:27:16PM -0500, Jeff Lightner via Ale wrote:
>> I like LVM because it allows one to quickly change layouts without having to
>> undo anything. One can add to an existing LV more easily than to existing
>> partitions. One also doesn't run up against partition boundaries causing
>> issues when a new filesystem is needed. A new LV can be added so long as
>> you have space.
>
> Only a few days ago I had the value of LVM on a single drive laptop
> handily demonstrated -- I migrated the contents of a LUKS-encrypted 512G
> drive to a 1TB drive, roughly doubling the sizes of all volumes in the
> process, without having to go through a very time-consuming parition
> realignment.
>
> The longer version:
>
> On xmas eve a precocious youngster knocked a beverage into my open
> laptop bag. While Thinkpad Ts are tough, they aren't designed to be
> partially submerbed. Magic smoke escaped. I have nightly backups of
> critical stuff (/etc, /var, /home) but thankfully the old drive survived
> completely unscathed.
>
> /boot/efi (vfat) and /boot (ext4) were "classic" partitions; I doubled
> their size when creating the new partitions, dumped them over. the
> former was resized. Then I dumped the LVM PV over, and rebooted from the
> live USB stick into the restored system. From there I grew the PV to
> fill the rest of the disk, doubled the size of /'s LV, had /home use the
> remaining space, and live-resized /, /boot, and /home.
>
> From powering on the new system to being right where I left off took
> less than an hour, including data transfer -- dd sustained 1.1GB/s,
> limited by the NVMe<>USB dongle I was using. That broke my brain a
> bit...
>
> - Solomon
>
More information about the Ale
mailing list