ZFS in Buster

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

ZFS in Buster

Dan-363
Dear Debian developers,

ZFS 0.8 has been released with lots of improvements, notably encryption.

Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0
that prevents ZFS from using SIMD. The result is that ZFS won't be
usable in Buster. See the following issue
https://github.com/zfsonlinux/zfs/issues/8793

NixOS reverted that particular commit:
https://www.phoronix.com/scan.php?page=news_item&px=NixOS-Linux-5.0-ZFS-FPU-Drop

Debian is the "Universal Operating System" and gives the user the
option to choose. It provides "vim and emacs", "Gnome and KDE",
"Linux, Hurd, KfreeBSD, etc.". I think that Debian should also provide
the option to use ZFS with encryption.

Would it be possible to provide an alternative patched linux kernel
that works with ZFS?

The ZFS developers proposed the Linux developers to rewrite the whole
ZFS code and use GPL, but surprisingly the linux developers didn't
accept. See below:
https://github.com/zfsonlinux/zfs/issues/8314

Best,
Daniel

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Jonathan Carter (highvoltage)-2
Hi Dan

On 2019/05/28 18:43, Dan wrote:
> ZFS 0.8 has been released with lots of improvements, notably encryption.

Yep, it's an exciting feature.

> Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0
> that prevents ZFS from using SIMD. The result is that ZFS won't be
> usable in Buster. See the following issue
> https://github.com/zfsonlinux/zfs/issues/8793

Buster ships zfs-dkms version 0.7.12-2 though, which works just fine on
buster.

> NixOS reverted that particular commit:
> https://www.phoronix.com/scan.php?page=news_item&px=NixOS-Linux-5.0-ZFS-FPU-Drop
>
> Debian is the "Universal Operating System" and gives the user the
> option to choose. It provides "vim and emacs", "Gnome and KDE",
> "Linux, Hurd, KfreeBSD, etc.". I think that Debian should also provide
> the option to use ZFS with encryption.

Debian does offer that, ZFS runs fine on LUKS, I use that all the time
and it works just fine on buster.

Misattributing the intent behind the "Universal Operating System" will
never get you anywhere if you try to make a point in Debian. I suggest
you not try to abuse it like that.

> Would it be possible to provide an alternative patched linux kernel
> that works with ZFS?

I'm not making any kind of judgment call on this, I'm not on the kernel
team, but it's kind of late in the buster cycle to test a patch in the
kernel for a regression that doesn't manifest in buster, for a version
of software that isn't packaged in buster. My guess is that it's very
possible for bookworm, and also that by the time bookworm is released
the upstreams would've come to a solution.

> The ZFS developers proposed the Linux developers to rewrite the whole
> ZFS code and use GPL, but surprisingly the linux developers didn't
> accept. See below:
> https://github.com/zfsonlinux/zfs/issues/8314

That issue is closed because as the commenters rightly point out,
dual-licensing OpenZFS from cddl to cddl+gpl is impossible without the
permission of the original copyright owners (who clearly doesn't want to
do that).

-Jonathan

--
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Ian Jackson-2
Jonathan Carter writes ("Re: ZFS in Buster"):

> On 2019/05/28 18:43, Dan wrote:
> > ZFS 0.8 has been released with lots of improvements, notably encryption.
>
> Yep, it's an exciting feature.
>
> > Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0
> > that prevents ZFS from using SIMD. The result is that ZFS won't be
> > usable in Buster. See the following issue
> > https://github.com/zfsonlinux/zfs/issues/8793
>
> Buster ships zfs-dkms version 0.7.12-2 though, which works just fine on
> buster.

Of course it's in contrib, and not properly part of Debian.

> > NixOS reverted that particular commit:
> > https://www.phoronix.com/scan.php?page=news_item&px=NixOS-Linux-5.0-ZFS-FPU-Drop
...
> > Would it be possible to provide an alternative patched linux kernel
> > that works with ZFS?

I think this would be both unwise legally (without seeking additional
legal advice) and rather rude to the kernel upstream whose code is
then being reused without permission - indeed, contrary to their
explicitly stated intent.

We alread sought legal advice, with resulted in the halfway-house that
we can ship ZFS in contrib.

Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Dan-363
Hi Ian and Jonathan,

On Tue, May 28, 2019 at 10:26 PM Ian Jackson
<[hidden email]> wrote:
>
> I think this would be both unwise legally (without seeking additional
> legal advice) and rather rude to the kernel upstream whose code is
> then being reused without permission - indeed, contrary to their
> explicitly stated intent.
>
> We alread sought legal advice, with resulted in the halfway-house that
> we can ship ZFS in contrib.

Thanks a lot for you quick response and explanation.

Best,
Daniel

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Ansgar Burchardt-8
In reply to this post by Ian Jackson-2
Ian Jackson writes:
>> > Would it be possible to provide an alternative patched linux kernel
>> > that works with ZFS?
>
> I think this would be both unwise legally (without seeking additional
> legal advice) and rather rude to the kernel upstream whose code is
> then being reused without permission - indeed, contrary to their
> explicitly stated intent.

At least one commercial distribution (Ubuntu) has been distributing ZFS
binary modules as part of their Linux packages for some years and didn't
have any problems.

Debian doesn't provide prebuilt binary modules for out-of-tree modules
mostly to not have to care about them when the Linux ABI changes as
happens in many updates (including security/stable updates).

(Ubuntu avoids that by using `wget` to get the source for out-of-tree
modules like ZFS when building their src:linux package, something Debian
would probably not like that much...)

Ansgar

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Enrico Weigelt, metux IT consult-3
In reply to this post by Dan-363
On 28.05.19 18:43, Dan wrote:

> Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0> that prevents ZFS from using SIMD. The result is that ZFS won't be>
usable in Buster. See the following issue>
https://github.com/zfsonlinux/zfs/issues/8793
We recently had this discussion on lkml - yet another case of 3rdparty
folks that just don't follow the license rules.

It's not the kernel who broke zfs, it's zfs that broke itself. The
kernel is GPL, and they just have to follow the rules or go away.

OOT modules are conceptionally messy in the first place. It's sometimes
okay as an temporary workaround, until things get mainlined. But
intentionally keeping things oot for long time is just silly and creates
lots of more problems than it creates.

And they're even using now *deeply* arch-internal functions directly.

> NixOS reverted that particular commit:>
https://www.phoronix.com/scan.php?page=news_item&px=NixOS-Linux-5.0-ZFS-FPU-Drop
Intentional license violation. Not funny.

> Debian is the "Universal Operating System" and gives the user the> option to choose. It provides "vim and emacs", "Gnome and KDE",
If you wanna have something new included, you'll have to sit down and do
the actual work. In the end of the day, it's that simple.

> Would it be possible to provide an alternative patched linux kernel
> that works with ZFS?

You mean patching against the license ?

> The ZFS developers proposed the Linux developers to rewrite the whole
> ZFS code and use GPL, but surprisingly the linux developers didn't
> accept. See below:
> https://github.com/zfsonlinux/zfs/issues/8314

Wait, no. It's not that we refused anything (actually, I don't even
recall any decent discussion on that @lkml). There even wasn't anything
to accept or refuse - except the existing code, that is nowhere near
a quality where any maintainer likes to even have a closer look at.

The major problem is that ZoL always has been oot on purpose, which is
the wrong approach to begin with. That also leads to bad code quality
(eg. lots of useless wrappers, horrible maintenance, ...)

What ZoL folks could do is step by step rewrite it to use mainline
functionality where ever technically feasible and work closely with
upstream to introduce missing functionality. Obviously, their current
proprietary userland interface can't be accepted for mainline - it
has to be reworked to be conformant w/ standard uapi (eg. we already
have it for things like snapshots, deduplication, quotas, ...)

But it's up to ZoL developers to do the actual work and post patches
to lkml. There won't be anybody else doing that.


--mtx

--
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
[hidden email] -- +49-151-27565287

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Dan-363
In reply to this post by Jonathan Carter (highvoltage)-2
Hi Jonathan,

On Tue, May 28, 2019 at 8:50 PM Jonathan Carter <[hidden email]> wrote:

> On 2019/05/28 18:43, Dan wrote:
> > ZFS 0.8 has been released with lots of improvements, notably encryption.
>
> Yep, it's an exciting feature.
>
> > Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0
> > that prevents ZFS from using SIMD. The result is that ZFS won't be
> > usable in Buster. See the following issue
> > https://github.com/zfsonlinux/zfs/issues/8793
>
> Buster ships zfs-dkms version 0.7.12-2 though, which works just fine on
> buster.

My message was not accurate. I think that the commit has been
introduced in in 4.19.38 (released 2019-05-02). I think that Debian
Buster uses 4.19.37

https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.38

The commit also affects ZFS 0.7 because SIMD is used for checksum operations.

There might be a performance penalty in ZFS only if Debian Buster
upgrades to 4.19.38.

Best,
Daniel

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Ian Jackson-2
In reply to this post by Ansgar Burchardt-8
Ansgar writes ("Re: ZFS in Buster"):
> Ian Jackson writes:
> > I think this would be both unwise legally (without seeking additional
> > legal advice) and rather rude to the kernel upstream whose code is
> > then being reused without permission - indeed, contrary to their
> > explicitly stated intent.
>
> At least one commercial distribution (Ubuntu) has been distributing ZFS
> binary modules as part of their Linux packages for some years and didn't
> have any problems.

That doesn't prove anything other than that no-one felt it was
politically or financially expedient to sue.

AIUI Debian's position is still that summarised here:
  https://blog.halon.org.uk/2016/01/on-zfs-in-debian/
(sorry about the pale grey on white disease; it works well in w3m)

Are you trying to reopen that discussion ?  If so then you should be
CCing ftpmaster@ and leader@ probably...

Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Aron Xu-3
On Wed, May 29, 2019 at 8:55 PM Ian Jackson
<[hidden email]> wrote:

>
> Ansgar writes ("Re: ZFS in Buster"):
> > Ian Jackson writes:
> > > I think this would be both unwise legally (without seeking additional
> > > legal advice) and rather rude to the kernel upstream whose code is
> > > then being reused without permission - indeed, contrary to their
> > > explicitly stated intent.
> >
> > At least one commercial distribution (Ubuntu) has been distributing ZFS
> > binary modules as part of their Linux packages for some years and didn't
> > have any problems.
>
> That doesn't prove anything other than that no-one felt it was
> politically or financially expedient to sue.
>
> AIUI Debian's position is still that summarised here:
>   https://blog.halon.org.uk/2016/01/on-zfs-in-debian/
> (sorry about the pale grey on white disease; it works well in w3m)
>
> Are you trying to reopen that discussion ?  If so then you should be
> CCing ftpmaster@ and leader@ probably...
>

(With my Debian ZoL hat on.)

I don't know whether this is correct time to discuss about Debian's
position but it was a compromise. Having Mehdi Dogguy (DPL of the
time) and representatives of Software Freedom Conservancy on the
table, we talked about this very topic at DebConf 16 and agreed to put
ZFS into contrib for the good of our users.

ZFS is free and open source software, perfectly complies with DFSG for
main archive inclusion on its own, and we had another copy of the code
in FreeBSD kernel which is main. While putting it into contrib is a
very expressive language telling the world that Debian and, more
importantly SFC, would like to see that the licensing issue could have
a better resolution at the root. And this is exactly the compromise
that made ZFS possible to go through NEW.

Regards,
Aron

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Ben Hutchings-3
In reply to this post by Dan-363
On Wed, 2019-05-29 at 13:43 +0200, Dan wrote:

> Hi Jonathan,
>
> On Tue, May 28, 2019 at 8:50 PM Jonathan Carter <[hidden email]> wrote:
> > On 2019/05/28 18:43, Dan wrote:
> > > ZFS 0.8 has been released with lots of improvements, notably encryption.
> >
> > Yep, it's an exciting feature.
> >
> > > Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0
> > > that prevents ZFS from using SIMD. The result is that ZFS won't be
> > > usable in Buster. See the following issue
> > > https://github.com/zfsonlinux/zfs/issues/8793
> >
> > Buster ships zfs-dkms version 0.7.12-2 though, which works just fine on
> > buster.
>
> My message was not accurate. I think that the commit has been
> introduced in in 4.19.38 (released 2019-05-02). I think that Debian
> Buster uses 4.19.37
>
> https://cdn.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.19.38
>
> The commit also affects ZFS 0.7 because SIMD is used for checksum operations.
>
> There might be a performance penalty in ZFS only if Debian Buster
> upgrades to 4.19.38.
Which we will, some time soon.

Ben.

--
Ben Hutchings
Horngren's Observation:
              Among economists, the real world is often a special case.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Sam Hartman-5
In reply to this post by Aron Xu-3




I hope that we do not choose to open the zfs discussion at this time.

If it does get opened, I think my approach would be to try and educate
the community about the various different viewpoints, find text for GRs
that would allow key stakeholders to believe their positions were
respected and considered (and that we were setting global policy not
trying to unreasonably micromanage ftpmaster), and hold a vote.
I don't think we could come to a rough consensus on zfs as a project; we
have a position  that at least at the time was working for ftpmaster and
the zfs maintainers.


However please consider the following.
I think the Software Freedom Law Center (SFLC's) blog post on zfs
https://www.softwarefreedom.org/resources/2016/linux-kernel-cddl.html is
the most pro-zfs legalish position that seems credible to me.
I understand that blog post is not legal advice,  but it's the kind of
nuanced and complex reasoning you're going to get from a lawyer if
you're working to find a legally defensible way to be permissive.
That position basically depends on arguing that by their actions the
kernel community has interpreted the boundary of derivative works
somewhat different than the FSF typically does.  I haven't read the blog
post recently, but it basically argues that the kernel community could
if they choose make the boundary even more clear.
But a key take away is that they are arguing that it's the intent of the
copyright holders that matters here.
Yeah, that sucks for people who want clear answers because the intent of
the kernel copyright holders is mixed.

Except now we're seeing a different intent expressed.  We're seeing the
kernel developers choose to close off some interfaces.
So, even under a very permissive (but IMHO still legally credible)
interpretation, the kernel developers are moving *away* rather than
*towards* zfs not being permitted to use the SIMD interfaces.

I have really high confidence that even if you reopen the discussion,
you're not going to convince the project of a legal position more
permissive than that advanced by the SFLC.

And if you take the Software Freedom Conservancy (SFC)'s position
https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/-UUU:**--F1
*unsent wide reply to Aron Xu*   Bot L50    (Message SC:f MML Abbre
which is a fairly typical position from someone who values a strong GPL
over being permissive in what we allow users to do, well, the issue is
fairly cut & dry.

So if people really are uncomfortable with the position--if getting some
sort of real closure would be worth a month or so of putting together
educational material, rangling text for a GR, and having a vote, let's
do that.  I think it will be painful, but I do totally understand that
issues like this can be painful if you feel a position was not given
adequate consideration.
But no matter what we do I suspect we'll find that getting a project
level consensus to revert commits so zfs can use certain interfaces ends
up being very unlikely.
That's only my prediction.  As DPL, I'll run the discussion fairly if
that's what we need to do.
I'd rather spend time on other things unless this is something a
significant number of people in our community need.


Meanwhile I'd like to thank the zfs maintainers, the former DPL,
ftpmaster, and all the parties that contributed to the balance we have
today.

signature.asc (199 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Mo Zhou
Hi,

With my Debian ZoL maintainer hat + FTP trainee hat on, I didn't wish
to jump into this topic too early without a in-depth investigation...

On 2019-05-29 14:14, Sam Hartman wrote:
> And if you take the Software Freedom Conservancy (SFC)'s position
> https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/-UUU:**--F1

But I got an HTTP404 there.

> I'd rather spend time on other things unless this is something a
> significant number of people in our community need.

I maintain a bunch of packages for Debian. The only package about
which I received many private prodding mails, is exactly ZFS...

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Sam Hartman-3
In reply to this post by Sam Hartman-5
>>>>> "Sam" == Sam Hartman <[hidden email]> writes:

ke the Software Freedom Conservancy (SFC)'s
    Sam> position
    Sam> https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/-UUU:**--F1
    Sam> *unsent wide reply to Aron Xu* Bot L50 (Message SC:f MML Abbre

Ah, that's an interesting artifact of how cut&paste works in my
environment.:-(
https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/


--Sam

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Theodore Y. Ts'o
In reply to this post by Dan-363
On Tue, May 28, 2019 at 06:43:55PM +0200, Dan wrote:
>
> The ZFS developers proposed the Linux developers to rewrite the whole
> ZFS code and use GPL, but surprisingly the linux developers didn't
> accept. See below:
> https://github.com/zfsonlinux/zfs/issues/8314

I've read the thread, and there are a lot of misunderstandings of many
of the key people involved.  There also seems to be a lot of
misunderstanding of what the cause of the "hostility" is coming from
--- it is *not* about "sticking it to Oracle because they chose the
CDDL".

Also, it's not accurate that "linux developers didn't accept".  Ryan
sent a query to Linus, and Linus didn't respond.  I don't know if he
sent a single message, or whether he retried a couple of times.  A
failure to respond is not the same as a rejection.  There are plenty
of reasons why Linus might not have responded.

That being said, I don't propose to relitigate that whole thread here.
If people really care, feel free to contact me privately.  Or it could
be the case that since Ryan has closed, the ZoL community has already
moved on.  Which is also a fine outcome: from most of the upstream
Linux developers that I've talked to; not because they hold any
particular animus against ZoL.  It's just that no one feels
particularly interested in giving ZoL any kind of special treatment
--- the hostility around bypassing the requirements of GPL is about
exactly that; not the identity of the company or project trying to do
those particular things.

As Sam has noted, even in the most permissive interpretation, which is
that the Kernel has chosen to draw the lines around GPL compliance in
a different place as the FSF, does not mean that there are *no* lines.
Indeed, there are lines, and when they are violated, there will be
hostility and a refusal to cooperate, and ZoL is getting no better
*or* no worse treatment in that regard.

Bringing this back to Debian, my perception is that while there is not
unanimity about how the moral and legal requirements of the GPL
should be understood within Debian (just as there is also not
unanimity in the kernel community), the center of gravity within
Debian tends to be weighted towards the less permissive
interpretations of the GPL compared to the Linux Kernel community as
whole.  Which is to say, if you can't get the Linux Kernel community
folks to agree towards a certain flexibility towards evading the
CDDL/GPL license compatibility problems using techniques like "GPL
condoms", it is even less likely that the Debian community is going to
be willing to be so accomodating.

I also agree with Sam that the only way to know for sure is to have a
GR.  So you don't have to take our word for it; but please do
understand it's going to take a lot of community resources to make
that determination.  And there might be better uses of that time and
energy.

Regards,

                                        - Ted

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Mo Zhou
In reply to this post by Jonathan Carter (highvoltage)-2
Hi Dan and Jonathan,

On 2019-05-28 18:49, Jonathan Carter wrote:
> On 2019/05/28 18:43, Dan wrote:
>> ZFS 0.8 has been released with lots of improvements, notably encryption.
> Yep, it's an exciting feature.

I've already uploaded ZFS 0.8 to experimental. But beware, the original
0.8.0 release has a regression bug which may cause data loss. I've
patched
that bug in the 0.8.0-2 upload but we are not sure whether there are
still
regression bugs hiding there. We plan to postpone the 0.8.0 exp->sid
migration even after the Buster release.

>> Sadly the Linux Kernel has introduced a commit in kernel 4.19 and 5.0
>> that prevents ZFS from using SIMD. The result is that ZFS won't be
>> usable in Buster. See the following issue
>> https://github.com/zfsonlinux/zfs/issues/8793
>
> Buster ships zfs-dkms version 0.7.12-2 though, which works just fine on
> buster.

0.7.12-2 works with 4.19.37, but it will be badly broken when the first
point release of Buster is out. Foreseeable stable RC is grave enough:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929929

>> Would it be possible to provide an alternative patched linux kernel
>> that works with ZFS?

It seems that persuading the kernel team to patch the kernel
specifically for ZFS is impossible -- that's an dead end.
Another dead end is unblocking 0.7.13-1 .

Our last resort is to revert debdiff(0.7.12-2,0.7.12-5) and
apply the following patch (a part of the 0.7.12->0.7.13 diff):
https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730

This patch is not a solution but actually a compromise.

For personal Buster users there are two choices:
1. Pin kernel version (<< 4.19.38) and never upgrade. (assume
   the system admin knows what this means)
2. Patch the stable kernel locally.
3. Wait for 0.8.X/stable-backports which might contain a descent
solution.

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Mo Zhou
Hi,

On 2019-06-03 14:47, Mo Zhou wrote:
> It seems that persuading the kernel team to patch the kernel
> specifically for ZFS is impossible -- that's an dead end.

I made a mistake at this point. There is no SIMD bug in zfs
0.7.12-2. The true bug lies in the stable kernel update that
breaks stuff. We debian ZoL maintainers decided to do nothing
before the Buster release, and file an RC bug against the
kernel when 10.1 comes out.

How useful is a SIMD-less ZFS?

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Dan-363
In reply to this post by Mo Zhou
Hi Mo and Theodore,

On Sun, Jun 2, 2019 at 4:04 AM Theodore Ts'o <[hidden email]> wrote:

> Also, it's not accurate that "linux developers didn't accept".  Ryan
> sent a query to Linus, and Linus didn't respond.  I don't know if he
> sent a single message, or whether he retried a couple of times.  A
> failure to respond is not the same as a rejection.  There are plenty
> of reasons why Linus might not have responded.

Without a long-term agreement between the Linux Kernel and the OpenZFS
project the whole community will suffer. Opensource is about finding
paths to collaborate.

Now lustre is based on ZFS, this kernel regression will impact the HPC
community.

I'm not a lawyer, but I think that OracleZFS benefits from the
improvements made by OpenZFS. If there is an agreement between the
Linux Kernel and the OpenZFS project to convert OpenZFS to GPL, then
Oracle won't benefit any more from OpenZFS and they will be forced to
release the original ZFS code as GPL.

Below you can find an excerpt from the GitHub discussion.

On Jan 19 , 2019 Ryan wrote:

> Recent events WRT Linux 5.0 have made me reconsider user requests
> to pursue mainline inclusion. Linus Torvalds told me in person in 2014
> that he requires signed off from Oracle to merge the code.
> That is not happening, but it occurs to me that it should be possible to
> replace all Oracle copyrighted kernel code with new code over a long
> period of time (several years). This would bypass the need for Oracle’s
> signed off. It would also give us the ability to switch the kernel module
> to a dual CDDL/GPL.

> I suspect that the Illumos community would find the GPL
> (or even the LGPL) more acceptable than a BSD license. When
> Illumos was started, they stated that they do not want Oracle to be
> able to use their code without Oracle giving their changes back.

I understand that ZoL would like to convert OpenZFS to GPL, but they
will need the help and support of the Linux Kernel developers.


On Mon, Jun 3, 2019 at 4:47 PM Mo Zhou <[hidden email]> wrote:
>
> 0.7.12-2 works with 4.19.37, but it will be badly broken when the first
> point release of Buster is out. Foreseeable stable RC is grave enough:
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929929
>

This Linux kernel regression will break lot of computers and people
might loose data. Most of the users will have no clue why their
computer is not working and will blame Debian and the opensource
software.

Best,
Daniel

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Sam Hartman-3
Hi.

Thanks for bringing up this issue originally.
I think it has started some good discussion with the Debian zfs
maintainers.

However, I think this particular subthread about zfs has served its
purpose.

I cannot find anything in your message that is on topic for the
debian-devel mailing list.

Rehashing github discussions  between two non-debian parties doesn't
really seem of central import to the Debian developer community.

Discussing what the open zfs and kernel community should do and how they
should work together is certainly off-topic for debian-devel.

There are certain zfs discussions that might be on-topic for
debian-devel, but this particular subthread does not appear to be one of
them.
Thanks,

--Sam

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Ian Jackson-2
In reply to this post by Mo Zhou
Mo Zhou writes ("Re: ZFS in Buster"):
> I made a mistake at this point. There is no SIMD bug in zfs
> 0.7.12-2. The true bug lies in the stable kernel update that
> breaks stuff. We debian ZoL maintainers decided to do nothing
> before the Buster release, and file an RC bug against the
> kernel when 10.1 comes out.

I am hoping I have misunderstood.

Here is what I read from your message:

 * Prior to Daniel ([hidden email])'s message of last Tuesday, the
   Debian ZoL maintainers were aware of this precise difficulty
   surrounding the upstream __*fpu* symbols and ZoL.

 * The Debian ZoL maintainers collectively knew that this problem
   would not affect buster immediately, but would very likely affect a
   Linux kernel version which the kernel team would want to ship in a
   buster point releease.

 * The intention seems perhaps to have been to allow this latent
   problem to release with buster; and, then, to use the "released"
   status of ZoL in buster contrib, as a lever to try to have the
   kernel symbol change reverted in Debian's version of a forthcoming
   buster Linux kernel update, in that expected buster point
   release. [1]

 * The Debian ZoL maintainers did not seek a conversation with Debian
   kernel maintainers or the wider Debian project about this issue.

 * This lack of communication was deliberate.

I have a lot of respect for the energy you personally have brought to
your Debian work and the contributions you have made.  But I would
find behaviour such as I have described, if that is what occurred,
totally unacceptable.

If any of us in Debian become aware that any kind of problem or
adverse interaction will arise between our work, and that of other
contributors, it is our duty to promptly and candidly inform those
other contributors.

That is true even if we think those other contributors may disagree
with us, and if their likely response will be difficult for us.
Indeed, if we expect that their likely response will be adverse,
hiding the information is *more* rather than less serious.

It is very much Not OK to try to create Facts On The Ground while our
co-contributors remain in ignorance of our intent.

Please tell me I have misunderstood your message.

Regretfully,
Ian.

[1] As a matter of practical politics, I think any such strategy would
be clearly doomed, and not just because of the evidence of bad faith,
but also because Debian's overall attitude to GPL compliance issues
like this one is, as others have noted, very firm, and because of the
secondary status of contrib.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: ZFS in Buster

Sam Hartman-3

In our code of conduct we all made a commitment to start by assuming
good faith of of our community.
I'd like to remind us all to do that.


Ian, the zfs maintainers have definitely been working in good faith.
There was an unblock request filed May 9 attempting to address this
issue.

If you had been following debain-release you would have known that it
was unlikely to be approved.
And in fact it was not approved.

However, it's in line with a number of other unblock requests that we'd
all agree were submitted in good (if perhaps wishful) faith by people
trying to value their packages.

I'm not happy with the tone of the message from the zfs maintainers to
the kernel team.
But no, the zfs maintainers have been struggling to address this as best
they are able, and they have been public with their comments in the
right fora throughout the process.
There has been no hiding here.

There's a lot of frustration.

I could wish for better communication.

I could wish for a lot of things.  For example, I could wish that Oracle
would license zfs under the GPL and make a lot of us happier about the
whole thing.

Please have some respect and work with people who are trying to make
Debian great in the ways that matter to them.  Whether that's
protectingcopyleft, the stability of our releases, or the needs of our
users hoping for the latest and fastest features.

12