Changes in 5.8.x cause compsize/bees failure

Changes in 5.8.x cause compsize/bees failure

[A L]

I noticed that in (at least 5.8.6 and 5.8.8) there is some change in 
Btrfs kernel code that cause them to fail.

For example compsize now often/usually fails with: "Regular extent's 
header not 53 bytes (0) long?!?"

Bees is having plenty of errors too, and does not succeed to read any 
files (hash db is always empty). Perhaps this is an unrelated problem?

Re: Changes in 5.8.x cause compsize/bees failure

[Oliver Freyermuth]

Am 12.09.20 um 19:13 schrieb A L:
> I noticed that in (at least 5.8.6 and 5.8.8) there is some change in Btrfs kernel code that cause them to fail.
> For example compsize now often/usually fails with: "Regular extent's header not 53 bytes (0) long?!?"

I noticed the same after upgrade from 5.8.5 to 5.8.8 and reported it to compsize:
 https://github.com/kilobyte/compsize/issues/34
However, since it's userspace breakage, indeed it's probably a good idea to also report here. 

Since you see it with 5.8.6 already and I did not observe it in 5.8.5, this should pin it down to the 5.8.6 patchset. 
Sadly, I don't have time at hand for a bisect at the moment, and at first glance, none of the commits strikes me in regard to this issue (I don't use qgroups on my end). 

> 
> Bees is having plenty of errors too, and does not succeed to read any files (hash db is always empty). Perhaps this is an unrelated problem?
> 
> 

Re: Changes in 5.8.x cause compsize/bees failure

[Filipe Manana]

On Sat, Sep 12, 2020 at 6:27 PM Oliver Freyermuth
<o.freyermuth@googlemail.com> wrote:
>
> Am 12.09.20 um 19:13 schrieb A L:
> > I noticed that in (at least 5.8.6 and 5.8.8) there is some change in Btrfs kernel code that cause them to fail.
> > For example compsize now often/usually fails with: "Regular extent's header not 53 bytes (0) long?!?"
>
> I noticed the same after upgrade from 5.8.5 to 5.8.8 and reported it to compsize:
>  https://github.com/kilobyte/compsize/issues/34
> However, since it's userspace breakage, indeed it's probably a good idea to also report here.
>
> Since you see it with 5.8.6 already and I did not observe it in 5.8.5, this should pin it down to the 5.8.6 patchset.
> Sadly, I don't have time at hand for a bisect at the moment, and at first glance, none of the commits strikes me in regard to this issue (I don't use qgroups on my end).
>
> >
> > Bees is having plenty of errors too, and does not succeed to read any files (hash db is always empty). Perhaps this is an unrelated problem?
> >

Can any of you try the following patch and see if it fixes the issue?

https://pastebin.com/vTdxznbh

Thanks.

> >



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

Re: Changes in 5.8.x cause compsize/bees failure

[A L]

On 2020-09-12 21:45, Filipe Manana wrote:
> On Sat, Sep 12, 2020 at 6:27 PM Oliver Freyermuth
> <o.freyermuth@googlemail.com> wrote:
>> Am 12.09.20 um 19:13 schrieb A L:
>>> I noticed that in (at least 5.8.6 and 5.8.8) there is some change in Btrfs kernel code that cause them to fail.
>>> For example compsize now often/usually fails with: "Regular extent's header not 53 bytes (0) long?!?"
>> I noticed the same after upgrade from 5.8.5 to 5.8.8 and reported it to compsize:
>>   https://github.com/kilobyte/compsize/issues/34
>> However, since it's userspace breakage, indeed it's probably a good idea to also report here.
>>
>> Since you see it with 5.8.6 already and I did not observe it in 5.8.5, this should pin it down to the 5.8.6 patchset.
>> Sadly, I don't have time at hand for a bisect at the moment, and at first glance, none of the commits strikes me in regard to this issue (I don't use qgroups on my end).
>>
>>> Bees is having plenty of errors too, and does not succeed to read any files (hash db is always empty). Perhaps this is an unrelated problem?
>>>
> Can any of you try the following patch and see if it fixes the issue?
>
> https://pastebin.com/vTdxznbh
>
> Thanks.

I applied the patch on kernel 5.8.8-gentoo and it fixed my problems with 
both bees and compsize.

Thanks Filipe!

Re: Changes in 5.8.x cause compsize/bees failure

[Filipe Manana]

On Sat, Sep 12, 2020 at 9:36 PM A L <mail@lechevalier.se> wrote:
>
> On 2020-09-12 21:45, Filipe Manana wrote:
> > On Sat, Sep 12, 2020 at 6:27 PM Oliver Freyermuth
> > <o.freyermuth@googlemail.com> wrote:
> >> Am 12.09.20 um 19:13 schrieb A L:
> >>> I noticed that in (at least 5.8.6 and 5.8.8) there is some change in Btrfs kernel code that cause them to fail.
> >>> For example compsize now often/usually fails with: "Regular extent's header not 53 bytes (0) long?!?"
> >> I noticed the same after upgrade from 5.8.5 to 5.8.8 and reported it to compsize:
> >>   https://github.com/kilobyte/compsize/issues/34
> >> However, since it's userspace breakage, indeed it's probably a good idea to also report here.
> >>
> >> Since you see it with 5.8.6 already and I did not observe it in 5.8.5, this should pin it down to the 5.8.6 patchset.
> >> Sadly, I don't have time at hand for a bisect at the moment, and at first glance, none of the commits strikes me in regard to this issue (I don't use qgroups on my end).
> >>
> >>> Bees is having plenty of errors too, and does not succeed to read any files (hash db is always empty). Perhaps this is an unrelated problem?
> >>>
> > Can any of you try the following patch and see if it fixes the issue?
> >
> > https://pastebin.com/vTdxznbh
> >
> > Thanks.
>
> I applied the patch on kernel 5.8.8-gentoo and it fixed my problems with
> both bees and compsize.

Great, thanks for testing!
I'll send a proper patch on monday.

>
> Thanks Filipe!



-- 
Filipe David Manana,

“Whether you think you can, or you think you can't — you're right.”

Re: Changes in 5.8.x cause compsize/bees failure

[David Sterba]

On Sat, Sep 12, 2020 at 07:13:21PM +0200, A L wrote:
> I noticed that in (at least 5.8.6 and 5.8.8) there is some change in 
> Btrfs kernel code that cause them to fail.
> 
> For example compsize now often/usually fails with: "Regular extent's 
> header not 53 bytes (0) long?!?"
> 
> Bees is having plenty of errors too, and does not succeed to read any 
> files (hash db is always empty). Perhaps this is an unrelated problem?

The fix is now in stable queue, to be released in 5.8.10. Thanks for the
report!

Re: Changes in 5.8.x cause compsize/bees failure

[Zygo Blaxell]

On Tue, Sep 15, 2020 at 10:17:25AM +0200, David Sterba wrote:
> On Sat, Sep 12, 2020 at 07:13:21PM +0200, A L wrote:
> > I noticed that in (at least 5.8.6 and 5.8.8) there is some change in 
> > Btrfs kernel code that cause them to fail.
> > 
> > For example compsize now often/usually fails with: "Regular extent's 
> > header not 53 bytes (0) long?!?"
> > 
> > Bees is having plenty of errors too, and does not succeed to read any 
> > files (hash db is always empty). Perhaps this is an unrelated problem?
> 
> The fix is now in stable queue, to be released in 5.8.10. Thanks for the
> report!

And hopefully 5.4?  5.4.64 is also affected (and also fixed by Filipe's
patch).

Re: Changes in 5.8.x cause compsize/bees failure

[David Sterba]

On Tue, Sep 15, 2020 at 02:34:38PM -0400, Zygo Blaxell wrote:
> On Tue, Sep 15, 2020 at 10:17:25AM +0200, David Sterba wrote:
> > On Sat, Sep 12, 2020 at 07:13:21PM +0200, A L wrote:
> > > I noticed that in (at least 5.8.6 and 5.8.8) there is some change in 
> > > Btrfs kernel code that cause them to fail.
> > > 
> > > For example compsize now often/usually fails with: "Regular extent's 
> > > header not 53 bytes (0) long?!?"
> > > 
> > > Bees is having plenty of errors too, and does not succeed to read any 
> > > files (hash db is always empty). Perhaps this is an unrelated problem?
> > 
> > The fix is now in stable queue, to be released in 5.8.10. Thanks for the
> > report!
> 
> And hopefully 5.4?  5.4.64 is also affected (and also fixed by Filipe's
> patch).

Yes, complete list from
git://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git :

./queue-5.8/btrfs-fix-wrong-address-when-faulting-in-pages-in-the-search-ioctl.patch
./queue-4.14/btrfs-fix-wrong-address-when-faulting-in-pages-in-the-search-ioctl.patch
./queue-5.4/btrfs-fix-wrong-address-when-faulting-in-pages-in-the-search-ioctl.patch
./queue-4.19/btrfs-fix-wrong-address-when-faulting-in-pages-in-the-search-ioctl.patch
./queue-4.4/btrfs-fix-wrong-address-when-faulting-in-pages-in-the-search-ioctl.patch
./queue-4.9/btrfs-fix-wrong-address-when-faulting-in-pages-in-the-search-ioctl.patch

Re: Changes in 5.8.x cause compsize/bees failure

[Holger Hoffstätte]

On 2020-09-15 20:34, Zygo Blaxell wrote:
> On Tue, Sep 15, 2020 at 10:17:25AM +0200, David Sterba wrote:
>> On Sat, Sep 12, 2020 at 07:13:21PM +0200, A L wrote:
>>> I noticed that in (at least 5.8.6 and 5.8.8) there is some change in
>>> Btrfs kernel code that cause them to fail.
>>>
>>> For example compsize now often/usually fails with: "Regular extent's
>>> header not 53 bytes (0) long?!?"
>>>
>>> Bees is having plenty of errors too, and does not succeed to read any
>>> files (hash db is always empty). Perhaps this is an unrelated problem?
>>
>> The fix is now in stable queue, to be released in 5.8.10. Thanks for the
>> report!
> 
> And hopefully 5.4?  5.4.64 is also affected (and also fixed by Filipe's
> patch).

Yes, it is queued. You can always check what's coming:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/tree/queue-5.4

For other trees just see the parent dir.

-h