ZOL 0.8 Nears With RC3 Release - Big Update For ZFS On Linux

[mskarbek]

bpfilter puts the usermode helper inside the .ko file.

https://lwn.net/Articles/755919/

So this has really not much to-do with Dracut any more. 4.18 and newer kernels it possible for usermode helper and you kernel module to be 1 .ko file. You have to deal with Dracut or some other initramfs anyhow when using a kernel module that is not gplv2 as it cannot be legally merged into the main kernel image that you wish to use as your root file system..

Hmm... This user-mode blob stuff is actually quite interesting, thanks, I missed that but, as you noted, dracut/whatever is still in a play since we have CDDL situation here.

Please note you said here "actually do stuff that should be handled by kernel" when kernel has a Crypto API checksums should be the core kernel problem not being implemented in drivers..

Yes, I know what I had written and I wish that ZoL instead of using SPL/internal code was using native Linux kernel implementations not only when it comes to the crypto.

ZoL should have been submitting requests to make different items not GPL license years ago.

I'm not a ZoL developer so I can't answer why there was no such request. ZoL dos not implement their own crypto, it was a transplant from OpenSolaris/Illumos code base modified accordingly to fit the ZoL needs.

ZoL has not done the leg work on Linux kernel integration to make sure they are taking full advantage of what the Linux kernel can offer or even attempt to take advantage of what the Linux can offer.

Lack of that leg work is partially explainable by the need of keeping ZoL code in a shape easy to integrate in the upstream which is shared across multiple operating systems. ZoL was already criticized for diverging and OpenZFS started internal initiative to make different OpenZFS implementation more alike.
Interesting thing is that datto decided some time ago to bet on ZoL instead of Illumos so maybe we will see some improvements in the future. FreeBSD switching also to the ZoL implementation of ZFS rather then upstream Illumos is another catalyst of improvements (although not in Linux integration ofc). ZoL despite the fact that it is crippled and suffers from GPL-only in-kernel limitations became major (if not the main) force that drives OpenZFS development now.
Hopefully we will see in the near future more migrations from Illumos to ZoL (which will probably be more and more problematic for the OpenZFS itself and Joyent as a one of the main beneficiary of the Illumos code base right now) which may help advance Linux integration even further.
Sad thing is that ClusterHQ failed, they have made some work to help ZFS on Linux, fortunately one of that things - pyzfs is now adopted by ZoL and became part of it.

[oiaohm]

I'm not a ZoL developer so I can't answer why there was no such request. ZoL dos not implement their own crypto, it was a transplant from OpenSolaris/Illumos code base modified accordingly to fit the ZoL needs.

This is a big problem.

https://en.wikipedia.org/wiki/Comparison_of_operating_system_kernels#Supported_CPU_instruction_sets_and_microarchitectures

Where is your powerpc, mips and many more cpu support. Transporting from OpenSolaris/Illumos to Linux or BSD is problematic not enough CPU support.

Transplanting a extra crypto is still having your own crypto different to platform provided. With BSD and Linux having broader architecture support one of those should have been the transplanted crypto. Transplanting Illumos stuff is a big mistake and problem..

Lack of that leg work is partially explainable by the need of keeping ZoL code in a shape easy to integrate in the upstream which is shared across multiple operating systems.

Yes one thing it argue with easy share with upstream. Problem is sharing cross multiple operating systems this is not helping with because the upstream is not good enough.

Interesting thing is that datto decided some time ago to bet on ZoL instead of Illumos so maybe we will see some improvements in the future. FreeBSD switching also to the ZoL implementation of ZFS rather then upstream Illumos is another catalyst of improvements (although not in Linux integration ofc).

Makes sense for FreeBSD and other BSD to switch to ZoL at least it has some of the work around for the extra architectures that FreeBSD support that OpenSolaris/Illumos don't.

ZoL was already criticized for diverging and OpenZFS started internal initiative to make different OpenZFS implementation more alike.

That has been the problem. There is requirement for ZoL and Freebsd equal to break away from the Illumos code base. Really the freebsd/linux zfs implementations should not be based on the Illumos one if anything the Illumos one should be based on either the Linux or Freebsd one.

https://www.phoronix.com/scan.php?page=news_item&px=DRM-Next-KMOD-On-FreeBSD-11

"Linux KPI is the FreeBSD effort for providing a linux compadiblity layer."
There is more of a nightmare coming this KPI could be extended to file system drivers as well as graphics card drivers. FreeBSD developers have limited resources. Heck Illumos development is way lower in the resources department there is no way we can expect Illumos to support as much hardware as FreeBSD or Linux..

See the problem when you look at some depth on this problem what ZoL was doing is highly dangerous due to coping parts from a operating system with a lower peer review level to operating systems with higher peer review level resulting in avoiding using higher peer reviewed code. Yes both freebsd and linux kernels individually with crypto and another parts get more developers reviewing code than Illumos does.

I am not saying doing integration with Freebsd and Linux properly will be exactly simple. Yes if ZoF does proper intergration with Linux and FreeBSD Linux KPI both of those kernel could be using exactly the same driver source. This would also require restricting stuff to properly stable non GPL exports.

[oiaohm]

Maintaining the Unmaintainable: Picking up the Baton of a Secure Kernel Patchset

https://www.youtube.com/watch?v=4dIKbj_6diU

This video from LCA2019 is a good watch. Yes this is grsecurity. This has the right license yet attempted to be maintained outside the mainline Linux kernel. The result long term is horrible.

As more and more security patches are back ported to LTS kernels more and more out of tree stuff will break.

So ZoL broke due FPU functions being removed. But its only a matter of time due to being out of mainline that it will break to some other update.

Not right license makes sure you are doomed. Maintaining a driver with no goal of mainline is also another path to doomed long term. So from my point of view there is no trust-able ZFS support on Linux.

Options
1) remain a Linux kernel mode driver. Correct license and focus on mainlinig.
2) Being a fuse based file system and work on bpf support and the like for speed.

Any other path is doomed long term.

[Weasel]

Maintaining the Unmaintainable: Picking up the Baton of a Secure Kernel Patchset

https://www.youtube.com/watch?v=4dIKbj_6diU

This video from LCA2019 is a good watch. Yes this is grsecurity. This has the right license yet attempted to be maintained outside the mainline Linux kernel. The result long term is horrible.

As more and more security patches are back ported to LTS kernels more and more out of tree stuff will break.

So ZoL broke due FPU functions being removed. But its only a matter of time due to being out of mainline that it will break to some other update.

Not right license makes sure you are doomed. Maintaining a driver with no goal of mainline is also another path to doomed long term. So from my point of view there is no trust-able ZFS support on Linux.

Options
1) remain a Linux kernel mode driver. Correct license and focus on mainlinig.
2) Being a fuse based file system and work on bpf support and the like for speed.

Any other path is doomed long term.

Smells like bullshit. As if the "mainline" or "upstream" kernel never removes crap and filesystems. Newsflash: it does. So having it upstream doesn't make it any safer to break in the future when some retarded maintainer decides to "deprecate" or "remove" it.

[oiaohm]

Smells like bullshit. As if the "mainline" or "upstream" kernel never removes crap and filesystems. Newsflash: it does. So having it upstream doesn't make it any safer to break in the future when some retarded maintainer decides to "deprecate" or "remove" it.

Mainlining gets right of the breakage due to removed function in the Linux kernel for file system drivers because of the likes of Intel Project zero doing CI. As these CI systems build all include Linux kernel drivers and any mainline modification that breaks a mainline file system driver build will trigger a error against merging.

Not being mainline ZoL is going to in future break due to some other update out side their control. Being mainline someone wants to update something that will break ZoL or any other file system to merge they will have to update the file system as well.

Mainline does not mean that it cannot be deprecated. Mainline means the maintainer will not be repeatably hitting walls due to other people kernel changes.

Linux kernel removes stuff even from LTS kernels due to security reasons. Of course being mainline the person doing that security patch is also reasonable to fix any mainline file system driver they break in the process. Now not being mainline the maintainer of the driver/patch set is 100 percent responsible to fix how ever the mainline breaks it on them if they are in kernel mode.

[Weasel]

Mainlining gets right of the breakage due to removed function in the Linux kernel for file system drivers because of the likes of Intel Project zero doing CI. As these CI systems build all include Linux kernel drivers and any mainline modification that breaks a mainline file system driver build will trigger a error against merging.

Not being mainline ZoL is going to in future break due to some other update out side their control. Being mainline someone wants to update something that will break ZoL or any other file system to merge they will have to update the file system as well.

Mainline does not mean that it cannot be deprecated. Mainline means the maintainer will not be repeatably hitting walls due to other people kernel changes.

Linux kernel removes stuff even from LTS kernels due to security reasons. Of course being mainline the person doing that security patch is also reasonable to fix any mainline file system driver they break in the process. Now not being mainline the maintainer of the driver/patch set is 100 percent responsible to fix how ever the mainline breaks it on them if they are in kernel mode.

Like I said, for a user, it doesn't make it necessarily safer. It just changes the burden and puts it on the guy making the change, instead of the ZoL maintainers.

[oiaohm]

Like I said, for a user, it doesn't make it necessarily safer. It just changes the burden and puts it on the guy making the change, instead of the ZoL maintainers.

There is more to this. The person making the change understands why they are making the change. By the time the ZoL maintainers are finding out that X change has broken their items the person who is making the change and knows why has normally moved on to working on something else.

Items that are mainline hit way software wall issues so making forwards migration simpler.

Just like there is a Linus rule that what is userspace cannot be broken. What is something required by a mainline driver cannot be broken is also a Linus rule. So to remove a feature from mainline kernel space required patching all divers in mainline not to require that feature any more.

Remember with non mainline Linux kernel patches the workload will keep on increasing until they break.

Lets think about this for 1 min.

We have 100 faults that all break ZoL patch. If ZoL was mainline this could be 100 different developers to fix it. Since ZoL is not mainline this now become there team of 5 have to deal with all 100 faults. Rate of change of mainline Linux this could come a monthly number. How long until ZoL developers burn out.

Mainline patches are safer for end users because the maintainers of mainline drivers have a lower burn out rate due to not being left hanging repeatably with security and memory alterations they don't understand.

[devsk]

Options
1) remain a Linux kernel mode driver. Correct license and focus on mainlinig.
2) Being a fuse based file system and work on bpf support and the like for speed.

Any other path is doomed long term.

It hasn't doomed in a decade, so I doubt it will be doomed in near future. There are a lot of folks behind ZoL. We will figure something out, like we always do. I remember the early days when this project started with Brian from LLNL taking on various pieces like SPL and bringing them over to Linux. It was destined to be doomed then too. But its come a long way from there. ZoL is way different than one man/one company show drivers you may have seen doomed outside of kernel.

Can't say the same thing, with same certainty, about BTRFS, an in-kernel FS...;-)

[oiaohm]

It hasn't doomed in a decade, so I doubt it will be doomed in near future. There are a lot of folks behind ZoL. We will figure something out, like we always do. I remember the early days when this project started with Brian from LLNL taking on various pieces like SPL and bringing them over to Linux. It was destined to be doomed then too. But its come a long way from there. ZoL is way different than one man/one company show drivers you may have seen doomed outside of kernel.

Can't say the same thing, with same certainty, about BTRFS, an in-kernel FS...;-)

The reality here is the number of changed planed to be back-ported to stable kernels in the next 12 months is over double the prior 12 months. Also there are going to be a stack more API/ABI breaks.

There have been some quite large teams that have gone down in recent years.

One of the big changes coming will be the need to support Linux style cases insensitive file system BTRFS and most other file systems inside Linux kernel tree will get that simply.