> "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
>> in
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 throug
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
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 a
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 Bust
[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 pro
> "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 costl
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 Fre
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 th
> 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
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,
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.
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 t
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
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
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 soo
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
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
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 bu
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.
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
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.
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
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
> "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&pas
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/
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 c
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 L
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
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
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
> > tha
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
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 permissio
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 s
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
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 i
36 matches
Mail list logo
