Btrfs Zstd Compression Benchmarks On Linux 4.14

[phoronix]

Phoronix: Btrfs Zstd Compression Benchmarks On Linux 4.14

Of the many new features in Linux 4.14, one of the prominent additions is initial support for Zstd compression that is initially wired in for transparent file-system compression with SquashFS and Btrfs. Here are some benchmarks of Zstd Btrfs compression compared to the existing LZO and Zlib compression mount options.

http://www.phoronix.com/vr.php?view=25526

[digitus2001]

Would be great if something like 'compsize' could be used to also include compression statistics for each performance tool, as I am guessing there will be a relationship between performance, compression level and amount of data that was actually attempted to be compressed....

[tildearrow]

Very little typo:

due to failing up the entire 120GB SSD.. But of the

[davidbepo]

TL;DR if using compression use Zstd

[EarthMind]

I think you're dramatizing the results Michael. Zstd doesn't give "much better" results than the others. There is improvement yes, but for most users this is negligible. Only for big scale use where there are a lot of users and a lot of files, you can see a real advantage. But that's a different test case.

[arbition]

When I was working with virtual machine overlays with lots of zeros for sparsification (though this was a bug in the sparsification program) I found compression of the overlay file via FS compression made for a very good use case (image file was from a real disk, around 1TB)

[bnolsen]

do they support lz4? That would seem to be a good option as it shouldn't add any appreciable time either direction.

[Ropid]

do they support lz4? That would seem to be a good option as it shouldn't add any appreciable time either direction.

There's no lz4 support.

[Althorion]

Please, grep ZSTD /boot/config-4.14.0-999-generic. Enough with the cat abuse!

[s_j_newbury]

There's no lz4 support.

There was a patch enabling lz4 floating around for a while. I gave it a go and found it worked well, but lz4hc support was buggy and would fail on decompression at times. I believe, because of the unresolved lz4hc issue which presumably could have also affected standard compression although it never showed up, the code wasn't accepted upstream.