Compression is not working?

[sutyrin]

I've tested when /usr/lib/buttervolume is mounted with compress (also tested with compress-force) options. Everything written to plugin-backed volume is not compressed (according to btrfs usage stats and compsize utility)

In the same time, when I create a native btrfs volume at the same device, mount it locally completely unrelated to docker, and write large files — compression works as expected (according to btrfs and compsize).

[ccomb]

Thanks for reporting this issue
I've never used btrfs compression, I understand this is a choice during mount. I guess there are two mount operations causing the observed difference :

• the mount of /var/lib/buttervolume on the host, for accessing outside docker
• the mount of /var/lib/buttervolume by docker for use by the volume plugin

I imagine the latter may be done during the Volume.Mount plugin operation or something close. However I don't see any option to change how the mount is done by docker.
Maybe this is another argument to put in the return value {'Mountpoint': path, 'Err': ''} ?

[ccomb]

It looks like there is a bind-mount of the provided path by docker. I'm wondering whether a bind-mount can change the mount options of the underlying mount...

[niziak]

I didn't notice this issue. I've never use compression mount option. It is more convenient for me to use attributes chattr +c nextcloud_data inside /var/lib/buttervolume/volumes. Of course it works only for newly stored data (you can force recompression with btrfs defrag). My results are:

compsize nextcloud_data
Processed 79934 files, 257933 regular extents (257933 refs), 24730 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL       75%       53G          70G          70G       
none       100%       43G          43G          43G       
zlib        35%      9.2G          26G          26G      

BTW @ccomb thanks for great and simple plugin. I'm using it for almost 3 years without any issue!

[ccomb]

I finally found some time to try enabling compression.
It seems it's definitely possible, just by doing chattr +c just after creating the volume. When mounted by docker, the volume ends up using compression automatically for new files. Here is some simple test :

I create two volumes with buttervolume :

$ docker volume create -d anybox/buttervolume:HEAD volnocompress
volnocompress
$ docker volume create -d anybox/buttervolume:HEAD volcompress
volcompress

On one of them, I enable compression:

$ sudo chattr +c /var/lib/buttervolume/volumes/volcompress

Then I create a container using these two volumes:

$ docker run --rm -it -v volcompress:/volcompress -v volnocompress:/volnocompress debian:bullseye 

The used disk space is ~717GB:

root@d67286fd1123:/# df /
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/nvme0n1p4 953035776 717231288 235985544  76% /

Now I create a big file full of zeros in the volume supposed to be compressed:

root@d67286fd1123:/# cat /dev/zero > /volcompress/zero
^C
root@d67286fd1123:/# sync                 
root@d67286fd1123:/# ls -lh /volcompress/zero 
-rw-r--r-- 1 root root 4.9G Oct 11 21:05 /volcompress/zero

The used disk space is still ~717GB:

root@d67286fd1123:/# df /
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/nvme0n1p4 953035776 717396032 235826736  76% /

So compression seems to work.

I do the same in the uncompressed volume:

root@d67286fd1123:/# cat /dev/zero > /volnocompress/zero
^C
root@d67286fd1123:/# sync
root@d67286fd1123:/# ls -lh /volnocompress/zero 
-rw-r--r-- 1 root root 9.0G Oct 11 21:06 /volnocompress/zero

Now the used disk space is ~726GB:

root@d67286fd1123:/# df /
Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/nvme0n1p4 953035776 726823000 226410088  77% /

So I believe it is possible do add the same kind of option as for copy-on-write, but for compression.