Reclaim disk space in LXC raw images

[diego]

As it seems not possible to directly use chroot for LXC storage (due to having to do it in a hacky way and apparently having problems with "su") I am using the default raw image.

The problem with this images is that once that you use space, it is never released. For example, I have a container with 20GB assignated. It is only using 3 GB but time ago it reached 7GB so the image still weights 7GB. I tried the zeroing method (dd if=/dev/zero of=/mytmpfile inside CT) but it didn't worked, actually now it weights 11GB.

Is there a way to reclaim the used space back?


BTW +1 for fully supported chroot for LXC, even if it means some security risk and no disk space control .

 

[diego]

Isn't there any official way?

This is a huge problem as it is a wast of space once you have dozens containers. This means that the used space by containers can only grow so in some months you will have a lot space used by empty space. In the case above, havig 10 containers like this means having 40GB of wasted space and I barely used that container yet.

 

[wbumiller]

What do you mean by "hacky way"?
As for the 'su' problem, see http://forum.proxmox.com/threads/24781-SOLVED-LXC-and-Centos6-problems-with-su-and-mysqld
This bug is going to be fixed with the next updates.

The best you can do is use ZFS: provides directory storage with size limits (ZFS subvolumes)

The 'zeroing' only works if the underlying storage supports it and is capable of noticing such writes and makes it a sparse file. But 'dd' can actually counteract this (though you could try using conv=sparse).

LVM thin pools may become another option with future updates.

 

[diego]

What do you mean by "hacky way"?
As for the 'su' problem, see http://forum.proxmox.com/threads/24781-SOLVED-LXC-and-Centos6-problems-with-su-and-mysqld
This bug is going to be fixed with the next updates.

The best you can do is use ZFS: provides directory storage with size limits (ZFS subvolumes)

The 'zeroing' only works if the underlying storage supports it and is capable of noticing such writes and makes it a sparse file. But 'dd' can actually counteract this (though you could try using conv=sparse).

LVM thin pools may become another option with future updates.

I said hacky because using size=0 for containers does not work in the web interface and it doesn't look documented for the command line either (at least I couldn't find it).

If the su bug is fixed, does that mean that containers would operate normally? I mean just like with the raw image in terms of permissions? Also, if this is true, could you also enable to set size=0 in the interface?

The problem with ZFS is that it needs some hardware requirements that I don't meet and also I am currently managing everything with LVM (+1 for thin volumes).

Thanks for the dd advise. I will try that only for that VPS although it would be nice to get this fixed because I think it is a problem.

You have a really nice product, thanks a lot for your product and thanks a lot for your help!

 

[diego]

Another question regarding this empty space. When you backup a container via proxmox pve, does it clear the empty space before the compression (like with the dd conv=sparse option) or does it copy the whole image?

Thanks

 

[dietmar]

Another question regarding this empty space. When you backup a container via proxmox pve, does it clear the empty space before the compression (like with the dd conv=sparse option) or does it copy the whole image?

container backups works at file level, so that is quite efficient.

 

[fortechitsolutions]

A footnote on this thread in case it helps others. I came here via google search quite a while after this was an active thread but still seems relevant.

I've got a fairly current (Proxmox 7.4) cluster setup of a few nodes. And I've noted that LXC Containers - if I migrate from one node to another. The unwanted disk space used is brought over to the migration target host. But if I do the steps (a) Stop LXC Container (b) Backup (c) Destroy (d) move it / restore it on the new host. (e) Spin it up. Then this is more efficient in terms of reclaim of waste space - as Dietmar said in prior post - the backups of these containers are file-based so 'old unwanted blocks data' in the raw image do not carry over.

This solution also works if not migrating the VM, ie, if you want to reclaim space.
(A) Stop VM
(b) Back it up
(c) destroy the thing
(d) restore from backup
(e) now your fresh version has a 'thin' LXC Raw with no unwanted blocks and wasted space is not wasted. Until the next time you have massive log file growth etc. and then manually clean out crud inside the LXC Container, and then you have a 'partially inflated' thin raw file with wasted space again.

-Tim