Zfs: [Breaking Change] Depreciate LZJB

[Ornias1993]

Describe the problem you're observing

Currently ZFS still include LZJB and even makes it selectable as an algorithm.
While I understand the need (due to backwards compatibility) to keep decompression of LZJB a thing (at least at the moment), I would like to suggest deprecating it by doing the following:

• Make all LZJBcompressed datasets use LZ4 instead
• Show a warning at boot about LZJB being depricated and falling back to LZ4

This way users are more prepared for a future moment where LZJB is removed completely. But before an algorithm could be moved completely, I suggest we do more changes to make it easier to change previously compressed data to another algorithm. (I'll file another issue about that)

[DeHackEd]

That's a bit much. "ON means LZ4" is already how it works as long as LZ4 is supported by the pool which is sufficient. Users of modern pools would need to explicitly select lzjb to enable it and there is really no good reason to do that to the point I see it as a non-issue. Since we're 100% backwards compatible with older pools I think the way it is now - documented but not the default - is fine.

[Ornias1993]

@DeHeckEd

That's a bit much. "ON means LZ4" is already how it works as long as LZ4 is supported by the pool which is sufficient

I'm not talking about "ON", I'm talking specifically about explicit LZJB, which in my opinion should be made impossible to make it easier to remove later.

It increases the codebase in a needless way for useless backwards compatibility.

IMHO, people should be forced off of LZJB and it should be removed eventually completely.
By preventing people to select it, create a smaller problem when it is eventually removed.

If the goal is to be 100% backwards compatibile into eternity, than this Issue can be closed and we would have to just deal with an exponentially increasing codebase...

[scineram]

There can still be lzjb data, now and forever. You can never remove support.

[Ornias1993]

@scineram That is if you WANT to be 100% backwards compatible.

[DeHackEd]

We ARE 100% backwards compatible. You can create and import read/write a version 1 pool and it will work, including exporting the pool and sending it back to the old system that only supports v1. If it does not work that is grounds for reporting a bug. (Though realistically I think most people are version 23 or newer these days).

[Ornias1993]

@DeHackEd
I know we ARE, that is not of relevance to the question weither we WANT to be ;)

[behlendorf]

In my opinion, one of the major strengths of ZFS has always been that it takes backwards compatibility seriously. The expectation is that if you create a pool with even a very old version of ZFS you will be able to import it with the latest version. Personally, I feel strongly that this is the behavior we want and users should reasonably expect from a filesystem. We must retain at least decompression support for lzjb, and frankly the lzjb maintenance burden has been close to non-existent in practice.