Hi,
Has this been abandoned or will there be future attempts at syncing the
in-kernel zstd with the upstream project?
Tom
On Tue, Sep 28, 2021 at 8:24 PM Tom Seewald <[email protected]> wrote:
>
> Hi,
>
> Has this been abandoned or will there be future attempts at syncing the
> in-kernel zstd with the upstream project?
>
With the kind of crap that Nick has been getting from everyone, I'd be
surprised if he takes it up again anytime soon. As a bystander, I've been
incredibly disappointed with how this has "progressed" (read: stalled)
even though Nick is the developer and maintainer of zstd code.
--
真実はいつも一つ！/ Always, there's only one truth!
> On Sep 28, 2021, at 5:22 PM, Tom Seewald <[email protected]> wrote:
>
> Hi,
>
> Has this been abandoned or will there be future attempts at syncing the
> in-kernel zstd with the upstream project?
>
> Tom
Sorry for the lack of action, but this has not been abandoned. I’ve just been
preparing a rebased patch-set last week, so expect to see some action soon.
Since we’re not in a merge window, I’m unsure if it is best to send out the
updated patches now, or wait until the merge window is open, but I’m about to
pose that question to the LKML.
This work has been on my back burner, because I’ve been busy with work on
Zstd and other projects, and have had a hard time justifying to myself spending
too much time on this, since progress has been so slow.
Best,
Nick Terrell
On Wed, Sep 29, 2021 at 01:30:26AM +0000, Nick Terrell wrote:
> > On Sep 28, 2021, at 5:22 PM, Tom Seewald <[email protected]> wrote:
> > Has this been abandoned or will there be future attempts at syncing the
> > in-kernel zstd with the upstream project?
>
> Sorry for the lack of action, but this has not been abandoned. I’ve just been
> preparing a rebased patch-set last week, so expect to see some action soon.
> Since we’re not in a merge window, I’m unsure if it is best to send out the
> updated patches now, or wait until the merge window is open, but I’m about to
> pose that question to the LKML.
If you send it once merge window is open it's unlikely to be merged. The
code must be ready before it opens and part of linux-next for a week at
least if not more.
> This work has been on my back burner, because I’ve been busy with work on
> Zstd and other projects, and have had a hard time justifying to myself spending
> too much time on this, since progress has been so slow.
What needs to be done from my POV:
- refresh the patches on top of current mainline, eg. v5.15-rc3
- make sure it compiles and works with current in-kernel users of zstd,
ie. with btrfs in particular, I can do some tests too
- push the patches to a public branch eg. on k.org or github
- ask for adding the branch to linux-next
- try to get some feedback from people that were objecting in the past,
and of course gather acks or supportive feedback
- once merge window opens, send a pull request to Linus, write the
rationale why we want this change and summarize the evolution of the
patchset and why the full version update is perhaps the way forward
> -----Original Message-----
> From: David Sterba <[email protected]>
> Sent: Wednesday, 29 September 2021 8:07 PM
> To: Nick Terrell <[email protected]>
> Cc: [email protected]; linux-
> [email protected]; [email protected]
> Subject: Re: [GIT PULL][PATCH v11 0/4] Update to zstd-1.4.10
>
> On Wed, Sep 29, 2021 at 01:30:26AM +0000, Nick Terrell wrote:
> > > On Sep 28, 2021, at 5:22 PM, Tom Seewald <[email protected]>
> wrote:
> > > Has this been abandoned or will there be future attempts at syncing
> > > the in-kernel zstd with the upstream project?
> >
> > Sorry for the lack of action, but this has not been abandoned. I’ve
> > just been preparing a rebased patch-set last week, so expect to see some
> action soon.
> > Since we’re not in a merge window, I’m unsure if it is best to send
> > out the updated patches now, or wait until the merge window is open,
> > but I’m about to pose that question to the LKML.
>
> If you send it once merge window is open it's unlikely to be merged. The
> code must be ready before it opens and part of linux-next for a week at least
> if not more.
>
> > This work has been on my back burner, because I’ve been busy with work
> > on Zstd and other projects, and have had a hard time justifying to
> > myself spending too much time on this, since progress has been so slow.
>
> What needs to be done from my POV:
>
> - refresh the patches on top of current mainline, eg. v5.15-rc3
>
> - make sure it compiles and works with current in-kernel users of zstd,
> ie. with btrfs in particular, I can do some tests too
I have been running this patchset with btrfs on the latest stable kernels (5.12-14), and have not encountered any issues at all.
For AMD64 and AARCH64 you can add my
Tested-by: Paul Jones <[email protected]>
> - push the patches to a public branch eg. on k.org or github
>
> - ask for adding the branch to linux-next
>
> - try to get some feedback from people that were objecting in the past,
> and of course gather acks or supportive feedback
>
> - once merge window opens, send a pull request to Linus, write the
> rationale why we want this change and summarize the evolution of the
> patchset and why the full version update is perhaps the way forward
> On Sep 29, 2021, at 3:06 AM, David Sterba <[email protected]> wrote:
>
> On Wed, Sep 29, 2021 at 01:30:26AM +0000, Nick Terrell wrote:
>>> On Sep 28, 2021, at 5:22 PM, Tom Seewald <[email protected]> wrote:
>>> Has this been abandoned or will there be future attempts at syncing the
>>> in-kernel zstd with the upstream project?
>>
>> Sorry for the lack of action, but this has not been abandoned. I’ve just been
>> preparing a rebased patch-set last week, so expect to see some action soon.
>> Since we’re not in a merge window, I’m unsure if it is best to send out the
>> updated patches now, or wait until the merge window is open, but I’m about to
>> pose that question to the LKML.
>
> If you send it once merge window is open it's unlikely to be merged. The
> code must be ready before it opens and part of linux-next for a week at
> least if not more.
>
>> This work has been on my back burner, because I’ve been busy with work on
>> Zstd and other projects, and have had a hard time justifying to myself spending
>> too much time on this, since progress has been so slow.
>
> What needs to be done from my POV:
>
> - refresh the patches on top of current mainline, eg. v5.15-rc3
>
> - make sure it compiles and works with current in-kernel users of zstd,
> ie. with btrfs in particular, I can do some tests too
>
> - push the patches to a public branch eg. on k.org or github
>
> - ask for adding the branch to linux-next
>
> - try to get some feedback from people that were objecting in the past,
> and of course gather acks or supportive feedback
>
> - once merge window opens, send a pull request to Linus, write the
> rationale why we want this change and summarize the evolution of the
> patchset and why the full version update is perhaps the way forward
Thanks for the clear explanation, that was very helpful! I’ve already rebased
and re-tested myself. I’ll send out a request asking it to be added to linux-next,
and try to gather feedback/acks on that thread. I’ll prepare the rationale for the
linux-next request, so you all can get a chance to read it.
Thanks,
Nick
Hello.
On středa 29. září 2021 3:30:26 CEST Nick Terrell wrote:
> Sorry for the lack of action, but this has not been abandoned. I’ve just
> been
> preparing a rebased patch-set last week, so expect to see some action
> soon. Since we’re not in a merge window, I’m unsure if it is best to send
> out the updated patches now, or wait until the merge window is open, but
> I’m about to pose that question to the LKML.
>
> This work has been on my back burner, because I’ve been busy with work on
> Zstd and other projects, and have had a hard time justifying to myself
> spending
> too much time on this, since progress has been so slow.
Mind Cc'ing me on your new submission again please? I'm still running your old
one with 5.14 and 5.15, and it works flawlessly for me.
Thanks.
--
Oleksandr Natalenko (post-factum)