Logical volumes +ext4 resizing while mounted

cpaulett · 09-19-2022, 06:28 AM

Hi everyone,

the SSD I have on the laptop I'm using right now is formatted like so:

Code:

NAME
sda
├─sda1 [/boot, fat16, 1G]
└─sda2
  └─lvm-system
  ├─lvmSystem-volSwap [swap, 8G]
  ├─lvmSystem-volRoot [/, ext4, 50G]
  └─lvmSystem-volHome [/home, ext4, 421G]
sr0

I would like to get rid of the volSwap logical volume and merge its 8G into volHome. Just to be clear, the result would be:

Code:

NAME
sda
├─sda1 [/boot, fat16, 1G]
└─sda2
  └─lvm-system
  ├─lvmSystem-volRoot [/, ext4, 50G]
  └─lvmSystem-volHome [/home, ext4, 429G]
sr0

I presume the right sequence of commands to merge volSwap into volHome would be:

Code:

# swapoff -a && lvdestroy /dev/lvmSystem/volSwap && lvextend -l +100%FREE /dev/lvmSystem/volHome

Then, I presume I would also have to resize the ext4 partition inside volHome. Since it is ext4, I would go with resize2fs:

Code:

# resize2fs /dev/lvmSystem/volHome

And also, maybe I should remove the swap volume from my fstab (?).
I wrote this topic just want to make sure the sequence I elaborated is correct, and whether or not this can be performed while the laptop is on and the partitions are mounted.

michaelk · 09-19-2022, 07:37 AM

Why do you want to get rid of swap?

Depending on what distribution you are running and how it is configured swap might be used to hibernate the system.

cpaulett · 09-19-2022, 07:44 AM

Quote:

Originally Posted by michaelk

Why do you want to get rid of swap?

I recently switched to the linux-hardened kernel on Arch, and it currently does not support hibernation (see https://bugs.archlinux.org/task/63648). So, those 8G of swap are currently useless as I plan to stick to the Hardened kernel (I plan on re-compiling the hardened kernel to enable hibernation support, but not in the near future).

suramya · 09-19-2022, 07:52 AM

Quote:

Originally Posted by cpaulett

And also, maybe I should remove the swap volume from my fstab (?).
I wrote this topic just want to make sure the sequence I elaborated is correct, and whether or not this can be performed while the laptop is on and the partitions are mounted.

Never resize partitions when they are mounted as it will cause dataloss. You should boot with a LiveCD and do the operations from there. Also ensure that you have a verified backup before making the changes in case things go wrong.

cpaulett · 09-19-2022, 08:18 AM

Quote:

Originally Posted by suramya

Never resize partitions when they are mounted as it will cause dataloss. You should boot with a LiveCD and do the operations from there. Also ensure that you have a verified backup before making the changes in case things go wrong.

Ok, thank you. Concerning the commands I wrote, are they correct? Or is there something to be changed?

syg00 · 09-19-2022, 08:28 AM

Quote:

Originally Posted by suramya

Never resize partitions when they are mounted as it will cause dataloss. You should boot with a LiveCD and do the operations from there. Also ensure that you have a verified backup before making the changes in case things go wrong.

The general sentiment is ok (backup, then play), but the assertion is not. Resizing online with modern filesystems is fine - ext4 included.

lvextend accepts the " -r" parameter to manage the filesystem resize concurrently.
I am not familiar with lvdestroy - lvremove maybe ?.

michaelk · 09-19-2022, 08:34 AM

I am an advocate for having swap regardless of memory size for just in case use.
8GB is only about 2% of the total linux space.

rknichols · 09-19-2022, 08:37 AM

The ext4 filesystem can be safely enlarged while it is mounted. You just cannot shrink it while mounted.

You can enlarge the LV and the filesystem together by including the "--resizefs" ("-r") option in your lvextend command: :

Code:

lvextend -l +100%FREE -r /dev/lvmSystem/volHome
                      ^^

cpaulett · 09-19-2022, 08:41 AM

Quote:

Originally Posted by rknichols

The ext4 filesystem can be safely enlarged while it is mounted. You just cannot shrink it while mounted.

You can enlarge the LV and the filesystem together by including the "--resizefs" ("-r") option in your lvextend command: :

Code:

lvextend -l +100%FREE -r /dev/lvmSystem/volHome
                      ^^

Didn't know about that! Cool. One less possible source of mistakes. Thanks a lot

cpaulett · 09-19-2022, 08:45 AM

Quote:

Originally Posted by syg00

The general sentiment is ok (backup, then play), but the assertion is not. Resizing online with modern filesystems is fine - ext4 included.
I am not familiar with lvdestroy - lvremove maybe ?.

That's also what I knew. However, since I found a few diverging opinions online I decided to double-check before attempting.

Quote:

Originally Posted by syg00

I am not familiar with lvdestroy - lvremove maybe ?.

My bad. It is indeed lvremove.

computersavvy · 09-19-2022, 02:42 PM

You must disable the swap partition before you remove it.

The swapon command will tell you if it is active, and if so then the swapoff command should disable it.
If it was active then check /etc/fstab to see if it is listed as swap there and remove the entry so it does not activate on the next boot.

If the swapoff command was able to disable that partition then the lvremove command can be used to free up that space within the VG. It might however require a reboot after the /etc/fstab changes to ensure it is not in use; then do the lvremove.

Finally the lvextend command as shown in post #6 above can be used to expand the LV and fill the newly released space. All should be able to be done with the system active as long as the swap space is not actively being used.

Use 'man swapoff' or 'man swapon' to check all that is documented for those tools.

suramya · 09-25-2022, 03:43 PM

Quote:

Originally Posted by syg00

The general sentiment is ok (backup, then play), but the assertion is not. Resizing online with modern filesystems is fine - ext4 included.

lvextend accepts the " -r" parameter to manage the filesystem resize concurrently.
I am not familiar with lvdestroy - lvremove maybe ?.

Just because you can doesn't mean you should.

Resizing mounted partitions is technically feasible as you mentioned but is potentially risky enough that most partitioning software stop you from resizing a mounted disk. I tested with gparted and it wouldn't allow me to resize a mounted partition and only after I unmounted it I was allowed to resize.

The time savings you would get from resizing a mounted Root partition are miniscule enough that it is not worth the risk in my opinion. Plus unmounting the root partition will sure cause issues with the functioning of the OS anyways so there is that...

- Suramya

rknichols · 09-26-2022, 08:41 AM

Quote:

Originally Posted by suramya

The time savings you would get from resizing a mounted Root partition are miniscule enough that it is not worth the risk in my opinion. Plus unmounting the root partition will sure cause issues with the functioning of the OS anyways so there is that...

Enlarging a mounted ext4 filesystem is a routine and quite safe operation. The existing structures that would need to grow (the block group descriptor tables) are by default created with enough space reserved to allow the filesystem to grow to 1024 times its initial size.