I'm experimenting with LXC using Btrfs as a backing store. Btrfs allows for easy snapshot/deduplication and is ideal for spinning up several "pseudo-VMs".
The problem I'm having is that some of the apps I test dump a lot of data out to disk. I'm trying to limit the use of the Btrfs volume, so I assigned a quota to the subvolume created by LXC for a specific container.
The app does have a fail-safe test - when it sees less than a certain amount of disk space free on the filesystem it writes to (e.g. 512MB), it starts to clear out old logs to make room for new ones.
The problem is that, even with the quota applied, the LXC root filesystem still reports the full size of the host Btrfs filesystem.
Example: if my Btrfs filesystem is 250GB, and I create an LXC container using the
-B btrfs and
-s options, I now have a subvolume in the Btrfs filesystem representing the root of this new container. I then want to limit the space taken by the container, so I apply a qgroup limit of 32GB to the container. However, the
df command, when executed in the LXC container, still shows a total filesystem size of 250GB and a free space roughly based on the actual free space of the host filesystem; i.e. the quota limits are not displayed to
This means that my log app can fill up the entire quota and still believe it has 200+GB of space to write to, so thus it does not recycle off its old data. Eventually, the quota is exceeded, and thanks to the limitations of COW filesystems, I have to disable the quota and manually delete old logs - if the quota is still enforced at the same size, it is not possible to delete the data due to there being no extra space for the delete operation.
I've read enough and understand enough about Btrfs to understand that the idea of "free space" is confusing in Btrfs and can be a challenge to work out, but is there any way to even get a "ballpark" figure from within an LXC of how much quota space remains? Preferably this should be done by the standard APIs for getting disk free space (the ones that
df uses), since this means it would also apply to other apps accessing the filesystem and needing to know its approximate free space.
If I could conceivably get to within, say, 1GB or so of the actual free space (as provided by the quota), this would be enough for me to tweak the log expiry parameters so that the filesystem will not exceed quota.