Some statistics about BTRFS compression | Hacker News Reader

Some statistics about BTRFS compression

dataswamp.org

44 pointszdw27 comments

btrfs has had support for changing the compression level for some years.

I've been using zstd:2 (the default is 3), it compresses my data close to what zlib does while being pretty light on CPU.

https://docs.google.com/spreadsheets/d/1x9-3OQF4ev1fOCrYuYWt... (not mine)

https://linuxreviews.org/Comparison_of_Compression_Algorithm...

Also note that btrfs compression works on 128 KiB chunks and if you work with small files a lot (frontend work, etc), it may actually increase your SSD wear. I've seen this in practice.

Stats for my desktop PC (ZFS with LZ4):

  david@pc1:~$ /sbin/zfs get compressratio rpool tank
  NAME   PROPERTY       VALUE  SOURCE
  rpool  compressratio  1.93x  -
  tank   compressratio  1.20x  -

rpool contains the root filesystem and my home directory. tank contains movies, music, recordings and backups.

Mood It is impressive how much space you can save, with minimum CPU cost (It is there, but modern CPUs are so fast, well.. its okay)

I run NixOS, and on /nix/store itself, i get 2.32x compressratio :D

I use ZFS with LZ4 compression on my storage pool for NAS purposes, so its mostly music, movies and game stuff and it has an impressive 1.00x compression ratio, its not saved even 1%.

Seems unsurprising, as your data is already compressed.

I would have expected some savings from games but mayhaps not from lz4. Music and movies though, if lz4 had significant savings to provide these would have long been added to the media formats (likely in a more specialised and effective or efficient form).

If compression was enabled after the data was written it will not be compressed until the data is written again. Just some info not sure if it applies to your compression level situation or not.

For that kind of data I am surprised LZ4 isn't making it bigger unless ZFS declines to store the compressed version when it does.

That is correct, if the first few records (a virtual block size sorta) (not sure how many off the top of my head) don't compress well, it assumes that the file is not compressible and just writes the data out skipping the compression step.

No mention of if it’s force compression or not. Normal Btrfs compression can be unsuitable for some workloads where the beginning of files doesn’t compress but the rest does, Btrfs won’t compress the file if it appears pointless. Confused me when I tested it and can make a big difference!

https://btrfs.readthedocs.io/en/latest/Compression.html

Doesn't seem forced. The command listed is "btrfs filesystem defrag -czstd -r /" and the results include the "none" compression. That means most likely some files were rejected.

btrfs is a horrible mess that will likely lose your data. For the few production systems we implemented it on, every single normal failure that other file systems can recover from had resulted in complete loss. We've had to implement a project to rebuild all systems that used btrfs in order to remove it.

>btrfs is a horrible mess that will likely lose your data.

Meanwhile the bazillion petabytes on the world's synology NAS run fine, and are BTRFS.

Isn't synology running it hybridized with their own proprietary storage layer?

I believe it's a layer of mdadm and lvm rather than anything proprietary.

I could be wrong, but i think i remember that they have made some "magic" inside mdadm or lvm to allow btrfs self healing to work, and bypass the normal lvm self healing.

They tooted something around the release of DSM 7 that Btrfs now used native self healing instead of relying on lvm, but of course i can't find any documentation for it.

It's not proprietary, you can hook up the drives to a linux box and pull files off them just fine if your box dies. I've never had to do this, but I've seen others say they've done so successfully.

Ars Technica has acknowledged that stability has been achieved for single-disk filesystems. I've had no complaints, and the Fedora community has not reported major problems that I have heard.

"So, we'll repeat this once more: as a single-disk filesystem, btrfs has been stable and for the most part performant for years."

https://arstechnica.com/gadgets/2021/09/examining-btrfs-linu...

I dunno, I understand that the worst problems are in RAID, but it's only been a few years (<5y) since I lost 2 root filesystems to BTRFS on a laptop with just the one disk. I'm going to stay skeptical for a bit longer, although Fedora adopting it as a default does give me some hope that it'll at least get wider testing now.

I think fedora uses xfs by default not btrfs (at least in coreos version of f35)

https://fedoraproject.org/wiki/Btrfs#Default_filesystem,_on_... says they switched to BTRFS by default for the desktop edition with F33

They list the feature status here https://btrfs.wiki.kernel.org/index.php/Status It's not that raid has problems. Just one of the modes (raid5) is clearly documented as "unstable, don't use that".

It needs to be more than just avoiding tripping over itself, a real-world filesystem also needs to gracefully handle unclean poweroffs and such (and that's the kind of reliability I hope they will achieve..)

All of Facebook uses btrfs for their root filesystem (or did when I worked there). Millions of servers. They of course have the caveat of having kernel and btrfs developers working for them, and they run new kernels

they likely have huge replication infra on top of that which is resilient to individual partition problems.

I have been running btrfs at home with no losses. Mostly single, raid1 in a server. Array has been up ~4 years. While I doubt your comment that it will "likely lose your data", I am curious to know when (approximate kernel version/year) and how your losses occurred. There was clearly a history of data loss bugs, but it seems a little unfair to malign the system today after heaps of engineering went into stabilizing the filesystem.

Only somewhat related: My personal laptop is an older Dell Latitude 7370 (m7-6Y75) running Fedora 36. I had to reinstall using ext4 due to the performance impact of the default btrfs w/ compression. I was surprised at the difference it made. My disk throughput was nearly half.

I'm using btrfs for the first time (Ubuntu 22.04) and noticed that the performance is hugely reduced versus ext4, especially in kernels prior to 5.17. This was most evident installing papiris-icon-theme; there was a bug/inefficiency in how btrfs handles lots of files in the same directory. This has been fixed in 5.17, and while still slower than ext4 overall, for day-to-day usage (developer and gaming via steam/proton) I will stick with it for the ability to create snapshots.

Reply on news.ycombinator.com