Open sutyrin opened 3 years ago
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 :
/var/lib/buttervolume
on the host, for accessing outside docker/var/lib/buttervolume
by docker for use by the volume pluginI 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': ''}
?
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...
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!
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.
I've tested when
/usr/lib/buttervolume
is mounted withcompress
(also tested withcompress-force
) options. Everything written to plugin-backed volume is not compressed (according to btrfs usage stats andcompsize
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
).