Is fstrim needed on LVM-thick containers?

menathor

New Member
May 5, 2019
11
0
1
29
Hi all,

I've just discovered that debian/ubuntu has a bug with running fstrim inside containers. However, I am not using LVM-thin, just regular LVM. Therefore my raw disk image size won't change when files are deleted or added.

For this reason, I'm thinking maybe there's no need to run fstrim inside these containers anyway? Could someone confirm this? And should I still be running fstrim as a weekly cron job on the host?

Thanks!
 

LnxBil

Well-Known Member
Feb 21, 2015
4,217
408
83
Germany
For this reason, I'm thinking maybe there's no need to run fstrim inside these containers anyway? Could someone confirm this? And should I still be running fstrim as a weekly cron job on the host?
If you have a thin provisioned volume and you want your deleted space back ... hell yeah you need fstrim :-D
(You do not need it on ZFS)

I've just discovered that debian/ubuntu has a bug with running fstrim inside containers.
Please elaborate.
 

menathor

New Member
May 5, 2019
11
0
1
29
Thanks for the reply!

Sorry, just to clarify, my question was the opposite :) I'm * not* using thin provisioning. My LVM volumes are all fixed size thick volumes.

For this reason, I'm thinking that I don't need to run fstrim inside my containers. Is that correct?

Here's the link to the Ubuntu/debian bug:
https://bugs.launchpad.net/bugs/1589289

fstrim doesn't work inside unprivileged lxc containers atm. But hopefully that isn't an issue with thick volumes anyway...?
 

menathor

New Member
May 5, 2019
11
0
1
29

menathor

New Member
May 5, 2019
11
0
1
29
Hi all,

I've decided to just switch to priviledged containers. I'm the only one with SSH access to my machines so it's not really a security issue, and it solves this and several other problems. Also fstrim works perfectly in non-thin-provisioned storage when in a priviledged container. Although I'm still not sure whether it's even necessary or not...

Thank you for your replies!
 

LnxBil

Well-Known Member
Feb 21, 2015
4,217
408
83
Germany
I'm the only one with SSH access to my machines so it's not really a security issue, and it solves this and several other problems.
You should really reread about security, this sentence does not make any sense. If an attacker compromises a container (this happens normally without SSH), it is easier to break out of the container and do harm to the hypervisor.

An analogy would be to not lock your door because it takes to long to get your keys out of your pocket.

Also fstrim works perfectly in non-thin-provisioned storage when in a priviledged container. Although I'm still not sure whether it's even necessary or not...
What do you mean by "works perfectly"? You cannot trim a non-trimmable storage backend.
You have to differentiate between "does not produce an error" and "works as it should be".
 

menathor

New Member
May 5, 2019
11
0
1
29
Hi again.

Thanks for the info. Regarding the privileged containers, I'm just moving from a monolith setup where all 4 applications (web app, nginx, mysql, redis) were installed on bare metal, to separating them into containers for ease of migration and backup. From what I've read, running these 4 apps together on the host bare metal vs. separating them into 4 privileged containers presents the same security risk? I.e. if any one of these services are compromised in a "traditional" setup an attacker has access to the whole machine. Isn't the attack surface the same whether they're in separate containers or not? I would take exactly the same security precautions as I have with the "traditional" setup (firewalls, closing unnecessary ports, SSH keys etc).

Thanks for the info re: fstrim. From what I've read there is no benefit to trimming inside a fixed-size/thick provisioned disk image anyway, so I'll just stick to running it on the host.

Thanks!
 

LnxBil

Well-Known Member
Feb 21, 2015
4,217
408
83
Germany
Thanks for the info. Regarding the privileged containers, I'm just moving from a monolith setup where all 4 applications (web app, nginx, mysql, redis) were installed on bare metal, to separating them into containers for ease of migration and backup. From what I've read, running these 4 apps together on the host bare metal vs. separating them into 4 privileged containers presents the same security risk? I.e. if any one of these services are compromised in a "traditional" setup an attacker has access to the whole machine. Isn't the attack surface the same whether they're in separate containers or not? I would take exactly the same security precautions as I have with the "traditional" setup (firewalls, closing unnecessary ports, SSH keys etc).
You're right: compared to the monolith setup, a privileged container setup is better, but not as good as a non privileged containerisation setup. If you break out of a container, in the privileged setup, you're root on the hypervisor in the other setup you're just a user that has no rights and no home.

Thanks for the info re: fstrim. From what I've read there is no benefit to trimming inside a fixed-size/thick provisioned disk image anyway, so I'll just stick to running it on the host.
Trimming on the host does not offer any space reclaim of deleted space in your thick provisioned disk images so I don't know why you want to run it on the host. Normally, you don't have a lot of 'space fluctuation' on your hypervisor.
 

menathor

New Member
May 5, 2019
11
0
1
29
Thanks that's helpful. I have a few other things running directly on the host so even though there is not a lot of activity, I still run fstrim weekly as "good housekeeping" :)
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE and Proxmox Mail Gateway. We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get your own in 60 seconds.

Buy now!