ZFS On Linux Landing Workaround For Linux 5.0 Kernel Support

[starshipeleven]

aaand, unapproved post for Weasel because apparently posting a lot of links triggers vBullettin's highly advanced self-aware anti-spam feature.

[smitty3268]

Thank you for this. 8 pages of useless shit posting and name calling but this one buried in the middle was actually interesting to read.

Problem is the Linux kernel scheduler has changed since the ZFS guys did that.

https://linuxplumbersconf.org/event/2/contributions/194/

What to do after PREEMPT_RT is accepted into mainline
This means your messing around with the FPU now need to take out a protective lock. The performance profile since the merge of PREEMPT_RT is very different. Yes OpenSolaris/Illumos kernel does not have PREEMPT_RT and this is where ZoL accelerated SIMD check-summing comes from.

Sorry what was obvious reason to-do something under a Solaris/illumos kernel could be totally stupidity on the newer Linux kernel. Yes using SIMD by the FPU instruction is triggering locking that need to be PREEMPT_RT compatible.

Gee they have ported something from a different OS to Linux that may not in fact be compatible any more and it not only because the functions were removed the scheduler inside the Linux kernel now is now nothing like a OpenSolaris/Illumos kernel scheduler.

Basically we need the benchmarks. Linux 5.0 and newer kernels have the PREEMPT_RT stuff as default feature.

[Bucky Balls]

Ellerson is still really pee oded about the Android / Java lawsuit out come. It's all going to be hard ball from now out from him. Besides they need the revenue. They have had tons of venerability patches lately.

[ryao]

If Oracle relicensed to ZFS, it could be mainlined. (It would still need to go through the meticulous review process, etc, but at least no fundamental license objections.)

At this point, probably slim Oracle would relicense it to a GPL-compatible license.

Oracle is not able to relicense ZFSOnLinux by themselves. Myself and other copyright holders would need to sign off too. As far as getting agreement is concerned, it would be easier to rewrite all of the Oracle owned ZFS kernel code (which in itself would be a huge undertaking) than it would be to get Oracle to do anything.

[ryao]

They're not doing any such thing. This api was flagged deprecated for a bloody decade. The arrogance is Oracle/whoever is behind ZFS here. They should've fixed around this by now or relicensed. Upstream has no reason to provide anything here, they marked it deprecated long enough for the ZFS guys to react. Now that it's being removed people blame Linux devs for it. Ridiculous.

Oracle is not involved. It is an entirely community effort. The only Fortune 500 company with any connection to the project is Intel through Lustre, but only one guy who emailed the list has even a superficial connection to Intel (his employer is LLNL and they use Lustre). If an Oracle employee tried to contribute to the project in any way, they would be fired.

It is wrong to attribute open source ZFS anything to Oracle. Quite frankly, Oracle would likely be thrilled if OpenZFS were to disappear.

[ryao]

The "valuable fs" is not part of the Linux project, and is using a license that was specifically made to not allow said "valuable fs" to be merged in Linux.

Asking to make concessions "just because" is arrogant. Rules are rules.

Linus Torvalds himself told me that he does not have a problem with merging CDDL code. His problem is merging code owned by Oracle without their signed off. There really is not a license incompatibility if it is built as a separate module thanks to how we avoid touching GPL exported symbols. Before someone cites the Nvidia driver, I will point out that Nvidia’s license prohibits distributing kernel module binaries, which is the real reason nobody does it.

[oiaohm]

Linus Torvalds himself told me that he does not have a problem with merging CDDL code. His problem is merging code owned by Oracle without their signed off. There really is not a license incompatibility if it is built as a separate module thanks to how we avoid touching GPL exported symbols. Before someone cites the Nvidia driver, I will point out that Nvidia’s license prohibits distributing kernel module binaries, which is the real reason nobody does it.

That is not the only issue.

https://marc.info/?l=linux-kernel&m=154755787720823&w=2

To get into mainline kernel you normal have to go though the staging branch that means you would have to get past Greg. So you need more than 1 maintainers agreement.

Also wanting SIMD instructions so you can do accelerated checksums why is a big question. Why are there no requests to open up the crypto api with the features ZFS needs for checksuming. .

PREEMPT_RT means accessing the FPU has to be put behind a lock. So the function ZoL could have been using is wrong.

Nvidia case with dmabuf is important. It required Nvidia to sit down and work out exactly what they need. Please note word need not want. SIMD usage in ZoL driver is want. Need is accelerated checksum for ZoL. Then SIMD limits for accelerated checksum to x86 so SIMD is not exact meeting your need and may not be properly optimised due to not enough peer review sitting as CDDL code.

What is the need on the Linux kernel side. To use SIMD and the like registers have to be saved with addition PREEMPT_RT this means locking and other planned scheduler changes may equal locking changes in this area as well. So make all FPU/SIMD contact GPL only makes absolute sense allow merging mainline and dead lock detection to be performed in mainline and give freedom to those designing schedulers for the Linux kernel.

Reality here is if ZoL had entered the staging part of the Linux kernel tree you would have been told to clean that checksumming code out because it duplicating features Linux kernel already contains. The current fix of falling back to internal solution would not be except-able to stay long term in staging part of the Linux kernel tree. So there need to be work to sort out what functions you really do need the Linux kernel to expose so ZoL is not NRL syndrome on the Linux kernel result in the ZoL code base duplicating functionality the Linux kernel core provides..

Integration work is badly missing from the ZoL side.

Finally if you really are interested in making ZoL long term Linux mergable why are not all new submits to ZoL kernel space required to dual licensed under Linux kernel compatible license(GPLv2/BSD/MIT...)and CDDL. This would send a message to Orcale if you don't relicense we can slowly be surely chip piece by piece out the Orcale CDDL license parts and replace. Reality here if Oracle is trouble no need to be helping them long term.

[Emmanuel Deloget]

In short there's no real technical reason to remove them, just arbitrary or political or crap like "code cleanup" (seriously who the fuck cares about unused code with a small footprint?).

What about :

* Code that is not use rot
* Rotten code has bugs
* Bugs are exploited

Seems like a good technical reason to me.

Of course, I'm a developer, so this idea of cleaning things is quite alien to me. Wait. Oh, no.

Look, it's not like ZFS is never going to work again on linux ; the fact is "it will be a bit slower", which is not that hard. As I understand it, the main purpose of ZFS is not to compute checksum, and most of the work it does has nothing to do with checksums. It sometimes have to compute them (ok ; quite often ; just like it do on all the non-x86 arch where ZOL is supported).

[ryao]

That is not the only issue.

https://marc.info/?l=linux-kernel&m=154755787720823&w=2

To get into mainline kernel you normal have to go though the staging branch that means you would have to get past Greg. So you need more than 1 maintainers agreement.

Also wanting SIMD instructions so you can do accelerated checksums why is a big question. Why are there no requests to open up the crypto api with the features ZFS needs for checksuming. .

PREEMPT_RT means accessing the FPU has to be put behind a lock. So the function ZoL could have been using is wrong.

Nvidia case with dmabuf is important. It required Nvidia to sit down and work out exactly what they need. Please note word need not want. SIMD usage in ZoL driver is want. Need is accelerated checksum for ZoL. Then SIMD limits for accelerated checksum to x86 so SIMD is not exact meeting your need and may not be properly optimised due to not enough peer review sitting as CDDL code.

What is the need on the Linux kernel side. To use SIMD and the like registers have to be saved with addition PREEMPT_RT this means locking and other planned scheduler changes may equal locking changes in this area as well. So make all FPU/SIMD contact GPL only makes absolute sense allow merging mainline and dead lock detection to be performed in mainline and give freedom to those designing schedulers for the Linux kernel.

Reality here is if ZoL had entered the staging part of the Linux kernel tree you would have been told to clean that checksumming code out because it duplicating features Linux kernel already contains. The current fix of falling back to internal solution would not be except-able to stay long term in staging part of the Linux kernel tree. So there need to be work to sort out what functions you really do need the Linux kernel to expose so ZoL is not NRL syndrome on the Linux kernel result in the ZoL code base duplicating functionality the Linux kernel core provides..

Integration work is badly missing from the ZoL side.

Finally if you really are interested in making ZoL long term Linux mergable why are not all new submits to ZoL kernel space required to dual licensed under Linux kernel compatible license(GPLv2/BSD/MIT...)and CDDL. This would send a message to Orcale if you don't relicense we can slowly be surely chip piece by piece out the Orcale CDDL license parts and replace. Reality here if Oracle is trouble no need to be helping them long term.

The only reason we duplicate functionality in the crypto API is because we are not allowed to use the crypto API.

Requiring new contributions be dual licensed will never result in putting ZFS under a dual license. It also would not send any message to Oracle because Oracle literally does not care unless they have a financial loss/gain. You would need to get people to commit to rewriting most of the ZFS codebase to be able to consider going to a dual license. I am willing to have that discussion with other contributors, but this is not something that you could discuss in one day.

Thee is no point to having very much discussion on that without agreement on a path to mainline though.

[ryao]

What about :

* Code that is not use rot
* Rotten code has bugs
* Bugs are exploited

Seems like a good technical reason to me.

Of course, I'm a developer, so this idea of cleaning things is quite alien to me. Wait. Oh, no.

Look, it's not like ZFS is never going to work again on linux ; the fact is "it will be a bit slower", which is not that hard. As I understand it, the main purpose of ZFS is not to compute checksum, and most of the work it does has nothing to do with checksums. It sometimes have to compute them (ok ; quite often ; just like it do on all the non-x86 arch where ZOL is supported).

Given that there is a patch reimplementing the removed functionality in ZoL itself, ZoL will not become slower because of this.