ZFS On Linux Landing Workaround For Linux 5.0 Kernel Support

[cen1]

The arrogance from Linux devs on display here is astounding! breaking a valuable fs "just because" is ridiculous.

[starshipeleven]

Oooh, I see what they did and it is beautiful, they added code to detect on compile time if the kernel exposes the symbols.

This means that if a distro decides to patch their own kernel to expose them again (which is easy) the ZOL module will be built to use them.

[cen1]

Oooh, I see what they did and it is beautiful, they added code to detect on compile time if the kernel exposes the symbols.

This means that if a distro decides to patch their own kernel to expose them again (which is easy) the ZOL module will be built to use them.

Any sane distro should do it.

[ypnos]

The arrogance from Linux devs on display here is astounding! breaking a valuable fs "just because" is ridiculous.

They are not breaking any of their support promises. But they do constantly improve their codebase. Do you think code hygiene comes for free in a big, core project like Linux?
After all, the change we are talking about comes from this: https://lwn.net/Articles/643235/ To cite:

Over the past 10 years the x86 FPU has organically grown into somewhat of a spaghetti monster that few (if any) kernel developers understand and which code few people enjoy to hack.

So there is no "just because" here. ZFS was using a deprecated method that no longer exists. Now the Linux kernel devs do not change their own code licensing somewhere else in the kernel for this out-of-kernel module. That's it.

[starshipeleven]

The arrogance from Linux devs on display here is astounding! breaking a valuable fs "just because" is ridiculous.

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.

[sa666666]

Any sane distro should do it.

And circumvent the intent of the licensing in the process. Which is what you're advocating. But hell, as long as you get what you want, what does the license matter?

[Weasel]

ZOL just needs to implement the checksum code at their own, problem solved

Ah ye clueless champ talking like he knows what it's about.

[Weasel]

it don't matter what it's about - the internal kernel API is not supposed to be stable - it's that easy
when interfaces disappear deal with it

ZFS does a lot of stuff on it's own which normally is the mdraid or vfs layer

What has this to do with what I quoted? Don't cop out after saying some bullshit, bitch. It doesn't make it stink less.

[oiaohm]

The arrogance from Linux devs on display here is astounding! breaking a valuable fs "just because" is ridiculous.

Not able to be made mainline reduces it value a lot. Yes SIMD accelerated check-summing but not using decanted accelerated for check-sums that exists on some hardware either. Why not Solaris where ZFS was developed does not cover all the hardware Linux kernel does.

https://github.com/zfsonlinux/zfs/wi...e-requirements Having a starting requirement of 8G of memory is not good.

Btrfs and xfs prototypes with deduplication are a lot lighter on memory usage they are able to reuse the normal Linux kernel caches. Yes checksumming in Ext4. Btrfs and XFS will use hardware acceleration if it suits.

ZoL is very much round peg square hole that results in failing to take advantage of what the Linux kernel offers.

Oooh, I see what they did and it is beautiful, they added code to detect on compile time if the kernel exposes the symbols.

This is the way the code should have always been. Functions starting with __ are not stable exports from the Linux kernel and may be removed any time in the future without notice. So a well developed third party Linux kernel module is should have a auto fall back if function does not exist at built time for any __ starting function.

Any sane distro should do it.

We don't have the benchmarks yet. Saving state on FPU does cause system wide disruptions. It is possible that ZFS file system drivers will work out faster in many work loads the way the are now.

There is a lot of arrogance ZFS side. Like ZoL could be dual licensed for all new code to make migration to GPLv2 compatible more possible.


cen1 mainline developers are not required to support drivers using what should be internal only functions or provide functionality that results in you duplicating functionality the Linux kernel itself provided. ZoL is guilty of a lots of coding sins.

[bill_mcgonigle]

That's really ugly - disabling symbols just to hurt one open source project that an individual developer doesn't like. What good is this new Code of Conduct if on the other side of its implementation devs are targeting specific projects for trouble? I liked it better when Linus said 'fuck' and projects competed on merits, not thumbs on scales.

I get it, the in-kernel filesystems aren't getting many resources because ZFS is just better in most respects and most high-end users have wound up there, but not only does it hurt users, this has an ecosystem-wide energy penalty by preventing the use of SIMD instructions. I better not hear any of those jokers pretending to be "Green".