Linux Mint Forums

- Consider myself kind of a newbie on Linux since I'm a heavy Win and Cisco admin, but trying to learn fast. Decided to start with a NAS, decided that BTRFS was probably the right choice for my needs vs ZFS or ext4. So I gravitated to Linux Mint for that and the desktop.

- My goal here was to share a 2TB disk for backups using Samba and NFS using compression. Dedup would be nice.

- I created the BTRFS partition, mounted it using the compress-force=zlib option, and shared it out. So I copied 50GB of random, not compressed, backup data to it using Samba from a Win10 PC.

- Per my research to check it compression is on I checked dmesg and it does say "BTRFS info force zlib compression", but I also get below it a few lines below it "cgroup: new mount options do not match the existing superblock, will be ignored", maybe a different issue I couldn't figure out

- So I decided to see if I could tell if my 50GB of data was compressed and how much, which lead me to the "BTRFS filesystem df /mnt/Shared" command which is showing about 85GB used. What's the deal with that? Can someone point me in the right direction to why this is?

Thanks!

Is "compress-force=glib" a typo here in this post or also in your configuration? There is no glib compression algorithm. Supported algorithms are "zlib", "lzo" and "no" (for disabling compression when remounting).

As per the btrfs wiki you can't (currently) query the compressed size of files https://btrfs.wiki.kernel.org/index.php ... _a_file.3F. And the output of the btrfs fi df command you used needs interpretation as per the manpage and isn't useful for quick overview. Can you share the full output of btrfs fi df /mnt/Shared and btrfs fi du -s /mnt/Shared and also of sudo btrfs fi usage /mnt/Shared. Perhaps we can help make sense of the numbers.

I've been using btrfs without issues for 3 years but it has more "gotchas" than using an simpler filesystem like ext4. See for example the features that aren't stable yet https://btrfs.wiki.kernel.org/index.php/Status.

xenopeek wrote:Is "compress-force=glib" a typo here in this post or also in your configuration? There is no glib compression algorithm. Supported algorithms are "zlib", "lzo" and "no" (for disabling compression when remounting).

It's zlib, that was a mistype.

I've been using btrfs without issues for 3 years but it has more "gotchas" than using an simpler filesystem like ext4. See for example the features that aren't stable yet https://btrfs.wiki.kernel.org/index.php/Status.

Thanks for posting this link, I missed that page and from a few articles I thought BTRFS was a bit further along than it is. I found out though research last night that the inflated size of my data is due to block-size, and can be somewhat shrunk by using the "balance" option to fill empty blocks, not that it's really necessary. I was looking for something similar to transparent NTFS compression which I can't seem to find a solid solutions for, any recommendations for that? Not being able to query accurate compressed file sizes on disk seems like a deal breaker for me. I'm using ext4 right now but really hoping to find transparent compression, and maybe dedup, so that Windows didn't look so temping. ZFS has me worried about RAM (I only have 2GB to spare on the host) and no ECC.

Looking through which filesystems support transparent compression and work on Linux out of the box, see https://en.wikipedia.org/wiki/Compariso ... le_systems, the best options are either Btrfs or ZFS. I've not used ZFS so have no opinion to share.