[ale] to lvm or not lvm is my dillema

[jc.lightner at comcast.net]

+1

LVM makes life so much simpler when one runs into any kind of storage
allocation issue whether on a single drive or on a major disk array.

When we migrated from one large disk array to another we were able to use
PVMove.   Not only that we were able to do it for each environment (e.g. DB
instances) separately so we didn't overtax the software, database activity
or the overall arrays.  

-----Original Message-----
From: Ale <ale-bounces at ale.org> On Behalf Of DJPfulio--- via Ale
Sent: Friday, January 2, 2026 11:03 AM
To: Solomon Peachy via Ale <ale at ale.org>
Cc: DJPfulio at jdpfu.com
Subject: Re: [ale] to lvm or not lvm is my dillema

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
> 
_______________________________________________
Ale mailing list
Ale at ale.org
https://mail.ale.org/mailman/listinfo/ale
See JOBS, ANNOUNCE and SCHOOLS lists at
http://mail.ale.org/mailman/listinfo