Re: ZFS in Buster
> "Enrico" == Enrico Weigelt, metux IT consult writes: Enrico> On 01.07.19 21:06, Enrico Weigelt, metux IT consult wrote: Enrico> Hi, >> IIRC the whole things is actually about crypto stuff. Why don't >> zfs> folks just use the standard linux crypto api (potentially >> introduce a> Enrico> new algo if the existing ones aren't sufficient) ? Enrico> Addendum: just had a quick scan through the code and found a Enrico> completely own AES implementation. Almost certainly because the crypto apis in linux are gpl only and so module cannot actually call them. I'd like to echo Ian's comments from earlier today. You do seem to be dominating the list without managing to display adequate understanding of the points of view of other participants. It might be valuable to respond fewer times to the same thread and to spend a bit more time trying to understand others in the thread. If you're having trouble doing that it might be good to reach out to see if you could have an IRC, phone or real-life meeting with participants to get more onto the same page to participate more effectively. I think this is much more obvious on the git threads than the zfs threads. --Sam
Re: ZFS in Buster
On 01.07.19 21:06, Enrico Weigelt, metux IT consult wrote: Hi, > IIRC the whole things is actually about crypto stuff. Why don't zfs> folks > just use the standard linux crypto api (potentially introduce a> new algo if the existing ones aren't sufficient) ? Addendum: just had a quick scan through the code and found a completely own AES implementation. Seriously ? Completely redundant cipher implementations from an likely understaffed project is something I wouldn't like to have on my machines, not in the kernel. There're just too many pitfalls (especially w/ buggy x86 CPUs) in crypto programming - I wouldn't dare to implement that myself and run it on production systems. And for performance, many folks like to use hw acceleration. Linux crypto api already provides that. --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: ZFS in Buster
On 07.06.19 10:16, Philipp Kern wrote: Hi, > This would not be the case here. But crippling the performance would be> > indeed an option, even though this would make Debian much less relevant> for ZFS deployments and people would just go and use Ubuntu instead. Is it really necessary to to have some competition w/ Ubuntu on who's got the larger user base ? In which way is that relevant for the progress on Debian ? For me, personally, when working on FOSS, it never mattered how many users are out there - don't need to "sell" anything. > I personally wonder why a kernel which provides a module interface does > not provide a way to save FPU state, but alas, they made their decision. Because that's really low-level, arch specific stuff. I don't even recall any platform driver that ever cares about such things. From a kernel hacker/maintainer pov, the idea of having an arch specific filesystem driver, sounds really weird. This function IIRC just was a workaround for kvm, which always had been suboptimal and was replaced by a better solution. Since nobody used it anymore for quite some time, it got removed. And regarding LTS, I don't recall that Greg ever made any committment on not removing obsolete and used stuff (he's just reluctant of putting too much extra work into that for his lts trees). Of course, as users of kernel-internal APIs, only the in-tree stuff matters - this has always been the policy in Linux development (at least as far as I remember). IIRC the whole things is actually about crypto stuff. Why don't zfs folks just use the standard linux crypto api (potentially introduce a new algo if the existing ones aren't sufficient) ? --mtx -- Enrico Weigelt, metux IT consult Free software and Linux embedded engineering i...@metux.net -- +49-151-27565287
Re: ZFS in Buster
Hi zigo, According to the upstream temporary fix[1], the ZFS SIMD issue is specific to x86 architecture. It affects the following 3 parts of ZFS: 1. fast fletcher checksum (sse*, avx*) (used for data integrity check) 2. raidz 3. illumos crypto library Some architectures such as ppc64el are not affected at all. Plus, ZFS encryption is a feature introduced since 0.8.0, and 0.7.X doesn't have it. [1] https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730 On 2019-06-09 19:55, Thomas Goirand wrote: > On 6/6/19 5:16 PM, Ondřej Surý wrote: >> If we cannot make the ZoL in Buster safe for our users it needs to be >> removed from the release > > My understanding is that the issue is only affecting the performance of > the encryption part of ZFS, right? If so, I don't see why we should > remove ZFS from Buster, if ZFS continues to work perfectly, as long as > one doesn't use the encryption feature. Some warning lines in the > release notes, explicitly telling we recommend against using ZFS > encryption would IMO be enough. > > Please let me know if I'm wrong. > > Cheers, > > Thomas Goirand (zigo)
Re: ZFS in Buster
On 6/6/19 5:16 PM, Ondřej Surý wrote: > If we cannot make the ZoL in Buster safe for our users it needs to be removed > from the release My understanding is that the issue is only affecting the performance of the encryption part of ZFS, right? If so, I don't see why we should remove ZFS from Buster, if ZFS continues to work perfectly, as long as one doesn't use the encryption feature. Some warning lines in the release notes, explicitly telling we recommend against using ZFS encryption would IMO be enough. Please let me know if I'm wrong. Cheers, Thomas Goirand (zigo)
Re: ZFS in Buster
[No need to Cc an extra copy, I've been a d-d subscriber since... the 1990s?] On 2019-06-08 13:00:02 -0400 (-0400), Sam Hartman wrote: > Jeremy Stanley writes: > > Your earlier message also implied the motives behind > > Conservancy's recommendations to be something other than a > > desire to protect projects relying on free/libre open source > > software licenses from making costly mistakes. Suggesting that > > their interpretation of these licenses is driven by an ulterior > > motive strikes me as a gross mischaracterization, particularly > > in light of the ways in which they (individually and > > collectively) have demonstrated a dedication to core values of > > software freedom over the years. > > I actually think that the SFC has a strong motive to defend > copyleft. Certainly their leaders have taken strong pro-copyleft > positions. > > I don't think it is negative to them to describe them that way at > all. I'll concede, I may have been reading too much into Aron Xu's accounting of the in-person debate, but it seemed like the implication was that Conservancy was working in their own self interest in this matter, and not simply out of a desire to protect the (possibly tenuous, as you also indicate) legal grounds underpinning the GPL and by extension those projects who have chosen the GPL to represent their needs. > I think there are times when the desire to establish a strong > copyleft is in conflict with the desire to accurately articulate > the legal risks associated with something Debian might do. [...] I wholeheartedly concur, which is why I contested the grounds for the suggestion that Debian was coerced into its current position regarding ZFS integration with the Linux kernel (I was not there for the face-to-face discussions, so all I have to go on is the established reputations of the parties involved). > And the fact is we don't know what would happen in the courts in a > lot of situations. I attended a session at Libreplanet this year > where a lawyer talked about what actual rulings the courts have > made about the GPL and copyleft. It's not clear. Cases like Oracle > V Google and the German Vmware case both surprised us in various > ways. Yes, I see the VMware result as a sort of victory. While it's unfortunate that the German courts effectively dismissed the appeal on technicalities without weighing in on the issue at stake, at least the vendor has agreed to cease future flagrant violation of license terms by removing Linux components from their proprietary software (even if this does nothing to address their past violation the Linux contrbutors' legally-documented wishes with regard to their copyright). But point taken, the choice to retroactively underpin the free/open software movement (I have trouble seeing the two in isolation from one another as some do) with copyright law is akin to building a house on a foundation of sand. > And there are cases where courts will listen to what happens in > practice. If everyone or a lot of people are interpreting a > license a particular way, that can potentially influence courts. > Case law matters and case law is influenced by what companies > actually do and how copyright holders and licensees actually use > software. > > > To be clear, I seriously doubt Conservancy (or more precisely, > > the fine individuals within Conservancy involved in debating > > this topic over the years) would have been "upset" if Debian > > chose to act counter to their opinions. I'm quite sure they know > > that they don't control the choices of the Debian community, and > > are therefore not responsible for any additional risk that > > Debian knowingly takes on itself or passes on to its users. > > It's not the risk that Debian passes on to its users. It's what > Debian says and what happens if that becomes part of an argument > in a court case. > > Also, even if it never comes up in court, Debian's actions could > influence others. If Debian takes a strong position it makes it > easier to argue that in order to get your software actually used, > you need to interpret the GPL strictly. If Debian takes a weaker > position then as a practical matter you can commercially succeed > by releasing CDDL works that are combined with GPL works, at least > until a court says you cannot. While I respect that concern for case law and precedent may be at the forefront of Conservancy's arguments and preferences in this matter, I prefer to look at the underlying reasons for this. I highly doubt they chose this stance for their own sake, but rather for the good of software relying on the licenses with which they are most closely affiliated. I've had plenty of discussions and been on the sidelines for plenty more where these individuals left me with no impression that they were motivated by anything other than the proliferation and preservation of software freedom. > I am quite certain that factors like this were considered by > Debian. It was more than just the
Re: ZFS in Buster
> "Jeremy" == Jeremy Stanley writes: Jeremy> Your earlier message also implied the motives behind Jeremy> Conservancy's recommendations to be something other than a Jeremy> desire to protect projects relying on free/libre open source Jeremy> software licenses from making costly mistakes. Suggesting Jeremy> that their interpretation of these licenses is driven by an Jeremy> ulterior motive strikes me as a gross mischaracterization, Jeremy> particularly in light of the ways in which they Jeremy> (individually and collectively) have demonstrated a Jeremy> dedication to core values of software freedom over the Jeremy> years. I actually think that the SFC has a strong motive to defend copyleft. Certainly their leaders have taken strong pro-copyleft positions. I don't think it is negative to them to describe them that way at all. I think there are times when the desire to establish a strong copyleft is in conflict with the desire to accurately articulate the legal risks associated with something Debian might do. I'd totally turn to the conservancy if I wanted advice on how to best defend copyleft. Similarly i'd totally turn to them if I wanted help with community GPL enforcement. But the individuals in the SFC (if not the organization) have a vested interest in the strong interpretation of the GPL. So do many parts of Debian. But not all: BSD and LGPL are also free software licenses and you can comply with the social contract without supporting copyleft at all. And the fact is we don't know what would happen in the courts in a lot of situations. I attended a session at Libreplanet this year where a lawyer talked about what actual rulings the courts have made about the GPL and copyleft. It's not clear. Cases like Oracle V Google and the German Vmware case both surprised us in various ways. And there are cases where courts will listen to what happens in practice. If everyone or a lot of people are interpreting a license a particular way, that can potentially influence courts.. Case law matters and case law is influenced by what companies actually do and how copyright holders and licensees actually use software. Jeremy> To be clear, I seriously doubt Conservancy (or more Jeremy> precisely, the fine individuals within Conservancy involved Jeremy> in debating this topic over the years) would have been Jeremy> "upset" if Debian chose to act counter to their Jeremy> opinions. I'm quite sure they know that they don't control Jeremy> the choices of the Debian community, and are therefore not Jeremy> responsible for any additional risk that Debian knowingly Jeremy> takes on itself or passes on to its users. It's not the risk that Debian passes on to its users. It's what Debian says and what happens if that becomes part of an argument in a court case. Also, even if it never comes up in court, Debian's actions could influence others. If Debian takes a strong position it makes it easier to argue that in order to get your software actually used, you need to interpret the GPL strictly. If Debian takes a weaker position then as a practical matter you can commercially succeed by releasing CDDL works that are combined with GPL works, at least until a court says you cannot. I am quite certain that factors like this were considered by Debian. It was more than just the legal risks that were considered. I have not talked to the conservancy yet (although they did reach out to me when this issue came up again). I have read some of the correspondance between the DPL at the time and the FSF and I can assure you that choosing an interpretation of the GPL that defended copyleft was something the FSF cared about. I will be completely unsurprised to learn that the conservancy also cared about interpreting the GPL in a manner that preserves copyleft. And again, this is a matter of interpretation. Vmware has taken a different interpretation and so far they've won their court cases.
Re: ZFS in Buster
On 2019-06-08 18:11:28 +0800 (+0800), Aron Xu wrote: > On Sat, Jun 8, 2019 at 5:33 PM Ondřej Surý wrote: > > On 8 Jun 2019, at 10:56, Aron Xu wrote: > > > Even further, it's distributed in the form of dkms source and > > > theoretically not in Debian (contrib) to save people of > > > Software Freedom Conservancy from being upset about losing > > > their position of Linux GPL enforcement. > > > > I don’t care much about the rest, I said what I wanted to say, > > but I strongly disagree with this statement. It’s both untrue > > and very rude. > > > > We (the Debian community) care about the software freedom and > > associated licensing because we care “the software freedom”, not > > to please or displease some people that deeply care about the > > same/similar thing. > > There's no point to be rude from me because I was on the table > when the face to face discussion happened. We care about software > freedom and we have agreed that we choose to keep SFC's position > for the good of free software ecology, so in turn we agreed to > ship ZFS in contrib (which is not an official part of Debian) for > the best of our users and community. [...] Your earlier message also implied the motives behind Conservancy's recommendations to be something other than a desire to protect projects relying on free/libre open source software licenses from making costly mistakes. Suggesting that their interpretation of these licenses is driven by an ulterior motive strikes me as a gross mischaracterization, particularly in light of the ways in which they (individually and collectively) have demonstrated a dedication to core values of software freedom over the years. To be clear, I seriously doubt Conservancy (or more precisely, the fine individuals within Conservancy involved in debating this topic over the years) would have been "upset" if Debian chose to act counter to their opinions. I'm quite sure they know that they don't control the choices of the Debian community, and are therefore not responsible for any additional risk that Debian knowingly takes on itself or passes on to its users. If they're going to be upset by anything, I expect it's projects unknowingly making poor choices which might otherwise have been avoided if only someone had given them some guidance. That they are passionate and steadfast in arguing their points is laudable, and does not itself indicate a lack of good judgement. The phrasing in your latest reply continues to paint the decision to ship ZFS in contrib as a compromise between Debian and Conservancy, rather than Debian making an informed choice based on advice from Conservancy (and others). Your apparent disagreement with the result comes across as though you're implying an adversarial relationship between Debian and Conservancy which I sincerely hope does not reflect the feelings of the community as a whole. As Harry Tuttle once said, "we're all in it together." -- Jeremy Stanley signature.asc Description: PGP signature
Re: ZFS in Buster
On Sat, Jun 8, 2019 at 5:33 PM Ondřej Surý wrote: > > > > On 8 Jun 2019, at 10:56, Aron Xu wrote: > > > > Even further, it's distributed in > > the form of dkms source and theoretically not in Debian (contrib) to > > save people of Software Freedom Conservancy from being upset about > > losing their position of Linux GPL enforcement. > > I don’t care much about the rest, I said what I wanted to say, but I strongly > disagree with this statement. It’s both untrue and very rude. > > We (the Debian community) care about the software freedom and associated > licensing because we care “the software freedom”, not to please or displease > some people that deeply care about the same/similar thing. > There's no point to be rude from me because I was on the table when the face to face discussion happened. We care about software freedom and we have agreed that we choose to keep SFC's position for the good of free software ecology, so in turn we agreed to ship ZFS in contrib (which is not an official part of Debian) for the best of our users and community. "Our priorities are our users and free software", and the current status quo is what we can do to make sure both our users and free software are not disregarded from being our priorities. I believe this is in no way untrue. Regards, Aron
Re: ZFS in Buster
> On 8 Jun 2019, at 10:56, Aron Xu wrote: > > Even further, it's distributed in > the form of dkms source and theoretically not in Debian (contrib) to > save people of Software Freedom Conservancy from being upset about > losing their position of Linux GPL enforcement. I don’t care much about the rest, I said what I wanted to say, but I strongly disagree with this statement. It’s both untrue and very rude. We (the Debian community) care about the software freedom and associated licensing because we care “the software freedom”, not to please or displease some people that deeply care about the same/similar thing. Ondrej -- Ondřej Surý
Re: ZFS in Buster
On Fri, Jun 7, 2019 at 4:16 PM Philipp Kern wrote: > > On 6/6/2019 8:09 PM, Aron Xu wrote: > > Key interest in the thread is getting some insights about how to deal > > with the awkward situation that affects ZFS experience dramatically - > > Linux will remove those symbols in LTS kernel release, although > > in-kernel symbols are never promised to be stable. I've been in touch > > with ZoL upstream to listen to their plans and wishes, so that we > > (Debian ZoL people) can take actions that serve best for our users and > > community. > > I will note that in terms of prior art Debian has in the past always > prioritized freeness over performance. Whenever there are binary blobs > involved to improve performance, we opted not to ship them unless they > could be reproduced using free software and have their source included. > > Of course in that case people were still free to install the binary > blobs from non-free, assuming that the blob was in fact distributable. > This would not be the case here. But crippling the performance would be > indeed an option, even though this would make Debian much less relevant > for ZFS deployments and people would just go and use Ubuntu instead. > I agree that we usually prefer free-ness and universal-ness over performance, you know Mo Zhou in this thread is actively pushing deep learning stuff into Debian and he is discovering a lot of way to exploit better performance while not being too invasive to existing culture. Also I'd like to mention, it could be a widespread misunderstanding that "when something is incompatible with GPL/Linux then it's likely non-free". ZFS itself is free and open source software, I don't think it's comparable to non-free blobs. Even further, it's distributed in the form of dkms source and theoretically not in Debian (contrib) to save people of Software Freedom Conservancy from being upset about losing their position of Linux GPL enforcement. > Still, crippling performance would still provide a lever and motivation > for upstream to come up with a way to disable the FPU on every supported > architecture one by one (if only on the most important one), even if > it's brittle and hacky. I personally wonder why a kernel which provides > a module interface does not provide a way to save FPU state, but alas, > they made their decision. > It is hard to interpret why Greg KH would like to disallow access to hardware features and I don't think I'm at the position to comment. There is another way around at implementation side though, when a kernel thread is going to use FPU, preempt is usually (if not always) disabled, so it's still possible to make use of those registers without messing up with all the kernel states. But it's still weeks to go before being able to have an PR upstream. We are confident to have a version of ZFS that could make use of vector instructions in several months, but it could be hardly possible to merge back to buster stable updates, so that we'll have to recommend people using stretch-backports which is fine. > In the great scheme of things doing things the slow way has forced > certain progress to happen in the past when it was painful enough. The > question I wonder is if we are relevant enough here to push the needle > or if essentially all other distributions (say Ubuntu) will dare not to > follow upstream here and carry a patch forever. > IIRC all major distributions have a series of downstream maintained patches being carried for very long time, like the aufs4 patchset in Debian kernel. But this is not the case for the FPU one because it's not technically complex but people tend to avoid something supposed to lead to heated discussion in some regard. Regards, Aron
Re: ZFS in Buster
On 6/6/2019 8:09 PM, Aron Xu wrote: > Key interest in the thread is getting some insights about how to deal > with the awkward situation that affects ZFS experience dramatically - > Linux will remove those symbols in LTS kernel release, although > in-kernel symbols are never promised to be stable. I've been in touch > with ZoL upstream to listen to their plans and wishes, so that we > (Debian ZoL people) can take actions that serve best for our users and > community. I will note that in terms of prior art Debian has in the past always prioritized freeness over performance. Whenever there are binary blobs involved to improve performance, we opted not to ship them unless they could be reproduced using free software and have their source included. Of course in that case people were still free to install the binary blobs from non-free, assuming that the blob was in fact distributable. This would not be the case here. But crippling the performance would be indeed an option, even though this would make Debian much less relevant for ZFS deployments and people would just go and use Ubuntu instead. Still, crippling performance would still provide a lever and motivation for upstream to come up with a way to disable the FPU on every supported architecture one by one (if only on the most important one), even if it's brittle and hacky. I personally wonder why a kernel which provides a module interface does not provide a way to save FPU state, but alas, they made their decision. In the great scheme of things doing things the slow way has forced certain progress to happen in the past when it was painful enough. The question I wonder is if we are relevant enough here to push the needle or if essentially all other distributions (say Ubuntu) will dare not to follow upstream here and carry a patch forever. Kind regards Philipp Kern
Re: ZFS in Buster
On Thu, Jun 6, 2019 at 11:16 PM Ondřej Surý wrote:
>
> Hey all,
>
> I understand the woes on all sides, but I believe the correct “Debian" way
> would be to drop ZoL from Buster release. Of course we can wait until it
> breaks after Linux kernel upgrade, but I would say it’s better to prevent the
> dance around removing the package from the buster and just not release with
> it.
>
Perhpas you have misread the thread, or have just partially get the
idea of current situation... Please be a bit more patient.
The situation here is about the kernel unexporting
__kernel_fpu_{begin,end}, which was EXPORT_SYMBOL, that will lead to a
future installation failure of zfs-linux/0.7.12-2 (testing). We
already have minimal patch to disable FPU usage when those symbols are
not available, so be relaxed because we have gatekeeper to make sure
it won't explode in stable.
Key interest in the thread is getting some insights about how to deal
with the awkward situation that affects ZFS experience dramatically -
Linux will remove those symbols in LTS kernel release, although
in-kernel symbols are never promised to be stable. I've been in touch
with ZoL upstream to listen to their plans and wishes, so that we
(Debian ZoL people) can take actions that serve best for our users and
community.
Best,
Aron
Re: ZFS in Buster
Hey all, I understand the woes on all sides, but I believe the correct “Debian" way would be to drop ZoL from Buster release. Of course we can wait until it breaks after Linux kernel upgrade, but I would say it’s better to prevent the dance around removing the package from the buster and just not release with it. I see no reason why ZoL should be treated differently than any other software in Debian. If we cannot make the ZoL in Buster safe for our users it needs to be removed from the release, and perhaps provided via buster-backports. This is neither the first nor the last software that would be treated like this, and honestly pragmatic approach here would just prevent hurt feelings on all sides long-term. Cheers, Ondrej -- Ondřej Surý ond...@sury.org > On 6 Jun 2019, at 16:03, Bastian Blank wrote: > > Hi Zigo > > On Thu, Jun 06, 2019 at 02:43:16PM +0200, Thomas Goirand wrote: >> In such case, would you consider maintaining this tiny patch? >> https://github.com/NixOS/nixpkgs/pull/61076/commits/7b77c27caa8617c82df5c5af6b9ce6ae010d7f9a > > Please read https://bugs.debian.org/929557. > > Thanks for following all security precautions. > > Bastian > > -- > I've already got a female to worry about. Her name is the Enterprise. > -- Kirk, "The Corbomite Maneuver", stardate 1514.0 >
Re: ZFS in Buster
Hi Zigo On Thu, Jun 06, 2019 at 02:43:16PM +0200, Thomas Goirand wrote: > In such case, would you consider maintaining this tiny patch? > https://github.com/NixOS/nixpkgs/pull/61076/commits/7b77c27caa8617c82df5c5af6b9ce6ae010d7f9a Please read https://bugs.debian.org/929557. Thanks for following all security precautions. Bastian -- I've already got a female to worry about. Her name is the Enterprise. -- Kirk, "The Corbomite Maneuver", stardate 1514.0
Re: ZFS in Buster
On 5/29/19 3:52 PM, Ben Hutchings wrote: > On Wed, 2019-05-29 at 13:43 +0200, Dan wrote: >> 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, In such case, would you consider maintaining this tiny patch? https://github.com/NixOS/nixpkgs/pull/61076/commits/7b77c27caa8617c82df5c5af6b9ce6ae010d7f9a Thanks for maintaining the kernel over the years. Cheers, Thomas Goirand (zigo)
Re: ZFS in Buster
Sam Hartman writes ("Re: ZFS in Buster"):
> Ian, the zfs maintainers have definitely been working in good faith
...
> There has been no hiding here.
OK, good. Thank you. I am very glad to hear that I got the wrong end
of the stick.
I wrote that mail yesterday so I could sleep on it. Today I got a
number of people to review it before I sent it. I was very much not
the only person who read the message from Mo Zhou that bad way.
So thank you for the clarification, which I think is important.
I'm sorry if my message was a ham-fisted or offensive way of getting
that clarification. I'm particularly sorry to Mo Zhou for positing a
wrong allegation.
> 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.
That is of course fine. I have no problem with that. Indeed, it is
sometimes only by asking for what you really want that you find out
what is possible.
I would like to encourage people to ask for things even if they think
the answer is quite likely to be No. (NB this is not the same thing
as asking the same or very similar question again, after getting No.)
And those of us with gatekeeper roles should tolerate that, and when
we say No we should give reasons, state clearly any boundaries that
need reinforcing, and if possible make helpful alternative
suggestions.
Thanks,
Ian.
--
Ian JacksonThese 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.
Re: ZFS in Buster
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.
Re: ZFS in Buster
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 (ganc...@gmail.com)'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 JacksonThese 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.
Please revert LTS kernel change that will break ZFS for Buster point releases
control: severity -1 grave Dear kernel maintainers, Buster will be released with 4.19.37 kernel. That's fine and it doesn't break ZFS. However, the changes introduced in 4.19.38 and linux 5.0 break ZFS. That means the current 0.7.12-2 will fail to build everywhere after the first Buster point release (with kernel version bump). A foreseeable stable RC is grave enough. Upstream has made a compromise to disable SIMD for kernels that received the breaking change: https://github.com/zfsonlinux/zfs/commit/e22bfd814960295029ca41c8e116e8d516d3e730 Based on these, we Debian ZoL maintainers have several possible choices: 1. unblock 0.7.13-1 (see rmadison -S zfs-linux) (it contains the above patch) 2. revert debdiff(0.7.12-2,0.7.12-5), apply the upstream patch and upload 0.7.12-6 through t-p-u. 3. ask kernel maintainers to revert problematic commits Freeze policy makes it difficult for the release team to accept solution 1. Solution 2 is able to eliminate bugs but I doubt how useful a SIMD-less ZFS is. Compared to the others, solution 3 is the best solution because there won't be any future breakage or significant performance loss. My position is solution 3, as it's the ***LTS KERNEL UPDATE*** that introduced breaking change breaks ZFS 0.7.12-2. It's not a bug of ZFS 0.7.12-2 at all. Debian ZFS users are sensitive because I and Aron often receive private user reports and prodding mails. That means reverting the problematic kernel commit is beneficial to our users. Our priorities are our users and free software, NOT to stick to the problematic breaking LTS update. I believe this is a kernel bug. Instead of submitting a grave RC for the 10.1 release, we'd better sort it out right now before the Buster release. Thanks, Mo
Re: ZFS in Buster
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
Re: ZFS in Buster
Hi Mo and Theodore, On Sun, Jun 2, 2019 at 4:04 AM Theodore Ts'o 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 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
Re: ZFS in Buster
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?
Re: ZFS in Buster
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.
Re: ZFS in Buster
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
Re: ZFS in Buster
> "Sam" == Sam Hartman 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 works in my environment.:-( https://sfconservancy.org/blog/2016/feb/25/zfs-and-linux/ --Sam
Re: ZFS in Buster
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...
Re: ZFS in Buster
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 Description: PGP signature
Re: ZFS in Buster
On Wed, 2019-05-29 at 13:43 +0200, Dan wrote: > Hi Jonathan, > > On Tue, May 28, 2019 at 8:50 PM 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. > > > > > 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 Description: This is a digitally signed message part
Re: ZFS in Buster
On Wed, May 29, 2019 at 8:55 PM Ian Jackson
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
Re: ZFS in Buster
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 JacksonThese 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.
Re: ZFS in Buster
Hi Jonathan, On Tue, May 28, 2019 at 8:50 PM 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. > > > 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
Re: ZFS in Buster
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=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 i...@metux.net -- +49-151-27565287
Re: ZFS in Buster
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
Re: ZFS in Buster
Hi Ian and Jonathan, On Tue, May 28, 2019 at 10:26 PM Ian Jackson 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
Re: ZFS in Buster
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=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 JacksonThese 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.
Re: ZFS in Buster
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=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) ⣾⠁⢠⠒⠀⣿⡁ Debian Developer - https://wiki.debian.org/highvoltage ⢿⡄⠘⠷⠚⠋ https://debian.org | https://jonathancarter.org ⠈⠳⣄ Be Bold. Be brave. Debian has got your back.
ZFS in Buster
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=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
