FSTRIM & PCT Lock

[Proxygen]

I ran fstrim on a container via `pct fstrim`. `pct list` shows the container with a fstrim lock.

i removed the lock with `pct unlock`. fstrim kept on running:

root     10358  0.2  0.1 322408 110876 ?       S    12:08   0:00 /usr/bin/perl -T /usr/sbin/pct fstrim 117
root     10361  0.0  0.0   5956  1072 ?        D    12:08   0:00 fstrim -v /var/lib/lxc/117/rootfs/

two questions:

a) does `pct fstrim` lock the container for writing? if yes, is it possible to run without locking the container for writing?

b) if A is yes, isn't the unlock operation supposed to stop the fstrim process??

 

[t.lamprecht]

i removed the lock with `pct unlock`. fstrim kept on running:

why?

a) does `pct fstrim` lock the container for writing? if yes, is it possible to run without locking the container for writing?

the fstrim operation locks the CT to avoid that one triggers a mount, or other operation during this.

b) if A is yes, isn't the unlock operation supposed to stop the fstrim process??

A fstrim cannot be really aborted in a common way, depending on the underlying storage, the fstrim command just does a few basic checks and tells the kernel to do the TRIM over an ioctl command, the kernel's block system may continue that command even if you kill the fstrim process.

 

[Proxygen]

why?

Because it causes the disk subsystem to become unusable, failing the services in the containers on that disk. Unfortunately I don't have a maintenance window to bring the machine down. So I can't run fstrim periodically, only when I reboot the server every couple of months.

the fstrim operation locks the CT to avoid that one triggers a mount, or other operation during this.

I assume it was OK to unlock it then, as long as I don't issue another pct command on that container, mount/backup/etc. right?

bottom line, as I understand the container can still write to its disk, but the system is unusable during trim. and it took over 1 hr on a firecuda 520 2TB

 

[t.lamprecht]

bottom line, as I understand the container can still write to its disk, but the system is unusable during trim. and it took over 1 hr on a firecuda 520 2TB

There's a huge spectrum of how fstrim works and impacts running systems... I have a lot systems where I do not notice it at all if I run a fstrim, and I have that one special NVMe (reputable "brand" manufacturer) in my private workstation which cannot handle it at all - triggering a fstrim there will make everything it touches and seemingly the whole Kernel IO path unusable..

So I know your pain, but besides trying to run it at those hours which are the most "off-hours" like window or, well, switching to another disk there's not much off suggestion I can imagine off..