LZ4 Compression Support Is Unlikely For Btrfs

[phoronix]

Phoronix: LZ4 Compression Support Is Unlikely For Btrfs

Patches have been posted several times now, but the Btrfs file-system is unlikely to offer support for LZ4 transparent file-system compression...

http://www.phoronix.com/scan.php?pag...kely-For-Btrfs

[thelongdivider]

I think LZ4 has some very nice advantages over the other algorithms, referencing

http://catchchallenger.first-world.i..._vs_LZ4_vs_LZO

The decompress times for files is extremely fast, which makes me think that for applications with many small files (e.g. /root or database applications) could seriously benefit from both having some level of compression and extremely fast decompress speeds. Hopefully they will reconsider... as it seems to be better than LZO in basically every way.

[Beherit]

I agree with the btrfs team that it's not justifiable to alter the entire disk format just to fit one single new compression algorithm into it. So what about altering it by making it modular? That way any user wanting to, could add lz4, snappy, bzip, lzma or whatever they like. Pretty much like the Linux kernel supports booting from xz/lzma/gzip/bzip/etc compressed kernel images.

A positive side-effect would be that any future algorithm surpassing the features and performance of lzo will be simple to add by just a module rather than forcing the btrfs team to, "once again", make changes they strongly oppose.

Most users wouldn't care, but it would shut up us whining power users who disagree (or just have slow enough computers) with the statement that lz4 isn't faster enough than lzo to be worth it.

[kernelOfTruth]

I agree with the btrfs team that it's not justifiable to alter the entire disk format just to fit one single new compression algorithm into it. So what about altering it by making it modular? That way any user wanting to, could add lz4, snappy, bzip, lzma or whatever they like. Pretty much like the Linux kernel supports booting from xz/lzma/gzip/bzip/etc compressed kernel images.

cough reiser4 cough

[AJenbo]

s/userpace/userspace

[BlueJayofEvil]

...supporing a new algorithm has impact on the the userpace tools or bootloader that has to be justified.

Why don't they try submitting changes to the bootloader/userpsace tools first to help allow support for LZ4? (or some kind of modular system like Beherit suggested?)

[man-walking]

Third option??
I'm shocked once again by the developers nth statement over LZ4 implementation, I would say LZ4 should be the *1st* option of BTRFS storage, it literally crushes LZO in terms of efficiency, 3x decompression speed at almost equal compression ratio and you still ask to prove a clear benefit ?

LZ4 makes LZO/snappy obsolete almost like does LZMA2 to bzip2, to the nowhereland (not enough strong, not that fast either)

[jacob]

I think that the btrfs devs have a point. Changing the disk format has huge consequences that almost always outweigh any benefit that a new compression algorithm might bring. There is no way to make this "modular", either grub can read a lz4 vmlinuz image or it can't.

[BlueJayofEvil]

I think that the btrfs devs have a point. Changing the disk format has huge consequences that almost always outweigh any benefit that a new compression algorithm might bring. There is no way to make this "modular", either grub can read a lz4 vmlinuz image or it can't.

You have a point about the modularity suggestion, but that still doesn't explain why they don't try to get the bootloader/userspace tool changes first before submitting kernel patches that would require them.

[jacob]

You have a point about the modularity suggestion, but that still doesn't explain why they don't try to get the bootloader/userspace tool changes first before submitting kernel patches that would require them.

I can't speak for them but I suspect that the bootloader and userland tools may not be too keen because it would impose additional support burden on them, and then again when LZ4's successor comes up, etc.