LZ4 Compression Support Is Unlikely For Btrfs

[BlueJayofEvil]

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.

That is true, but it still begs the question of why they didn't communicate with the bootloader developers and/or offer to help them beforehand, knowing full well that their own patches have very little chance of ever being accepted until the prerequisite changes are completed.

There is a possibility that they are making these LZ4 compression patches publicly known first, to show that bootloader work on such an endeavor wouldn't be in vain if they pursued such changes and thus maybe attract some developer attention that way.
But hey, maybe I'm just being too optimistic. *shrugs*

[jacob]

That is true, but it still begs the question of why they didn't communicate with the bootloader developers and/or offer to help them beforehand, knowing full well that their own patches have very little chance of ever being accepted until the prerequisite changes are completed.

There is a possibility that they are making these LZ4 compression patches publicly known first, to show that bootloader work on such an endeavor wouldn't be in vain if they pursued such changes and thus maybe attract some developer attention that way.
But hey, maybe I'm just being too optimistic. *shrugs*

Thinking about it, btrfs already supports per-file compression settings, so in theory as long as / and everything under /boot doesn't use lz4, the bootloader won't care. If Linux distros somehow enforced this, then it should be possible to add various extensions to btrfs without having to get them vetted by bootloaders first.

[BlueJayofEvil]

Thinking about it, btrfs already supports per-file compression settings, so in theory as long as / and everything under /boot doesn't use lz4, the bootloader won't care. If Linux distros somehow enforced this, then it should be possible to add various extensions to btrfs without having to get them vetted by bootloaders first.

That's a good point. I hadn't even considered that.

[Sachiru]

Meanwhile, LZ4 Support in ZFS is mainlined. I wonder how they managed to get that in there without making "major changes that compromise integrity"?

[starshipeleven]

because ZFS aren't usually boot drives, probably

[Beherit]

cough reiser4 cough

Could you please share details? I did a quick search but nothing comes up suggesting that reiser4 supports neither lz4 compression or modules to add it.

[Beherit]

Meanwhile, LZ4 Support in ZFS is mainlined. I wonder how they managed to get that in there without making "major changes that compromise integrity"?

If I recall correctly when reading the ZFS specifications a long time ago, compression is controlled by a flag using incremental numbering: 0 = no compression, 1 = LZJB compression, 2 = LZ4 compression, 3 = gzip, 4 = yet another one, etc.

Thus adding support for a compression algorithm doesn't break the filesystem or requires any major changes. Would someone try to mount a drive using an older version of the filesystem that doesn't support it, it results in an error such as, "compression type not supported" but not break anything or corrupt data.

I've no idea how this compares to the implementation in btrfs though, or if ZFS drives are bootable.

The Linux kernel itself does support LZ4 compression by adding the lz4 module (I've no idea if it's included as default). I'm guessing btrfs circumvents it though, as I can boot perfectly fine using LZO compression for my /boot directory even though there's no kernel module for LZO.

[kernelOfTruth]

Could you please share details? I did a quick search but nothing comes up suggesting that reiser4 supports neither lz4 compression or modules to add it.

I was referring more to the fact that reiser4 itself is built modularily with its plugin structure - so new features can be added easily rather than referring to lz4 compression support:


it recently got new features:
Precise real-time discard
https://forums.gentoo.org/viewtopic-...2.html#7704542

(meta)data checksums , Auto-punching holes
https://forums.gentoo.org/viewtopic-...6.html#7802026

[pal666]

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.

btrfs is a module already, but you can't make disk format modular. as soon as you change format, you can't read it with kernel or bootloader without support

[pal666]

Meanwhile, LZ4 Support in ZFS is mainlined. I wonder how they managed to get that in there without making "major changes that compromise integrity"?

toys do not have to deal with real life or backward compatibility