reiserfs broke between 4.9.205 and 4.9.208

reiserfs broke between 4.9.205 and 4.9.208

[Michael Brunnbauer]

hi

after upgrading from 4.9.205 to 4.9.208, I get errors on two different
reiserfs filesystems when doing cp -a (the chown part seems to fail) and
on other occasions:

 kernel: REISERFS warning (device sda1): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)

 kernel: REISERFS warning (device sdc1): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)

This behaviour disappeared after a downgrade to 4.9.205.

I understand there have been changes to the file system code but I'm not
sure they affect reiserfs, e.g.

 https://bugzilla.kernel.org/show_bug.cgi?id=205433

Any Idea?

Regards,

Michael Brunnbauer

-- 
++  Michael Brunnbauer
++  netEstate GmbH
++  Geisenhausener Straße 11a
++  81379 München
++  Tel +49 89 32 19 77 80
++  Fax +49 89 32 19 77 89 
++  E-Mail brunni@netestate.de
++  https://www.netestate.de/
++
++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
++  USt-IdNr. DE221033342
++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

Re: reiserfs broke between 4.9.205 and 4.9.208

[Randy Dunlap]

On 1/8/20 11:36 AM, Michael Brunnbauer wrote:
> 
> hi
> 
> after upgrading from 4.9.205 to 4.9.208, I get errors on two different
> reiserfs filesystems when doing cp -a (the chown part seems to fail) and
> on other occasions:
> 
>  kernel: REISERFS warning (device sda1): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)
> 
>  kernel: REISERFS warning (device sdc1): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)
> 
> This behaviour disappeared after a downgrade to 4.9.205.
> 
> I understand there have been changes to the file system code but I'm not
> sure they affect reiserfs, e.g.
> 
>  https://bugzilla.kernel.org/show_bug.cgi?id=205433
> 
> Any Idea?
> 
> Regards,
> 
> Michael Brunnbauer
> 

Looks to me like 4.9.207 contains reiserfs changes.

Adding CC's.

-- 
~Randy

Re: reiserfs broke between 4.9.205 and 4.9.208

[Jan Kara]

Hello,

On Wed 08-01-20 15:42:58, Randy Dunlap wrote:
> On 1/8/20 11:36 AM, Michael Brunnbauer wrote:
> > after upgrading from 4.9.205 to 4.9.208, I get errors on two different
> > reiserfs filesystems when doing cp -a (the chown part seems to fail) and
> > on other occasions:
> > 
> >  kernel: REISERFS warning (device sda1): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)
> > 
> >  kernel: REISERFS warning (device sdc1): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)
> > 
> > This behaviour disappeared after a downgrade to 4.9.205.
> > 
> > I understand there have been changes to the file system code but I'm not
> > sure they affect reiserfs, e.g.
> > 
> >  https://bugzilla.kernel.org/show_bug.cgi?id=205433
> > 
> > Any Idea?
> > 
> > Regards,
> > 
> > Michael Brunnbauer
> > 
> 
> Looks to me like 4.9.207 contains reiserfs changes.
> 
> Adding CC's.

Looks like a regression from commit 60e4cf67a582 "reiserfs: fix extended
attributes on the root directory". We are getting -EOPNOTSUPP from
reiserfs_for_each_xattr() likely originally from open_xa_root(). Previously
we were returning -ENODATA from there which error reiserfs_for_each_xattr()
converted to 0. I don't understand reiserfs xattrs enough to quickly tell
what should actually be happening after the Jeff's change - naively I'd
think we should just silence the bogus warning in case of EOPNOTSUPP. Jeff,
can you have a look?

Also Michael, I'd like to clarify: Does 'cp -a' return any error or is it
just that the kernel is spewing these annoying warnings?  Because from the
code reading I'd think that it is only the kernel spewing errors but
userspace should be fine...

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: reiserfs broke between 4.9.205 and 4.9.208

[Michael Brunnbauer]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]


Hello Jan,

On Thu, Jan 09, 2020 at 01:12:16PM +0100, Jan Kara wrote:
> Also Michael, I'd like to clarify: Does 'cp -a' return any error or is it
> just that the kernel is spewing these annoying warnings?  Because from the
> code reading I'd think that it is only the kernel spewing errors but
> userspace should be fine...

Yes, 'cp -a' returns errors and files are owned by root instead of the correct
user after copying as root.

Regards,

Michael Brunnbauer

-- 
++  Michael Brunnbauer
++  netEstate GmbH
++  Geisenhausener Straße 11a
++  81379 München
++  Tel +49 89 32 19 77 80
++  Fax +49 89 32 19 77 89 
++  E-Mail brunni@netestate.de
++  https://www.netestate.de/
++
++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
++  USt-IdNr. DE221033342
++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: reiserfs broke between 4.9.205 and 4.9.208

[Michael Brunnbauer]

[-- Attachment #1: Type: text/plain, Size: 1561 bytes --]


hi all,

is this been looked into? Do you need more information?

Regards,

Michael Brunnbauer

On Thu, Jan 09, 2020 at 01:30:41PM +0100, Michael Brunnbauer wrote:
> 
> Hello Jan,
> 
> On Thu, Jan 09, 2020 at 01:12:16PM +0100, Jan Kara wrote:
> > Also Michael, I'd like to clarify: Does 'cp -a' return any error or is it
> > just that the kernel is spewing these annoying warnings?  Because from the
> > code reading I'd think that it is only the kernel spewing errors but
> > userspace should be fine...
> 
> Yes, 'cp -a' returns errors and files are owned by root instead of the correct
> user after copying as root.
> 
> Regards,
> 
> Michael Brunnbauer
> 
> -- 
> ++  Michael Brunnbauer
> ++  netEstate GmbH
> ++  Geisenhausener Straße 11a
> ++  81379 München
> ++  Tel +49 89 32 19 77 80
> ++  Fax +49 89 32 19 77 89 
> ++  E-Mail brunni@netestate.de
> ++  https://www.netestate.de/
> ++
> ++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
> ++  USt-IdNr. DE221033342
> ++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
> ++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel



-- 
++  Michael Brunnbauer
++  netEstate GmbH
++  Geisenhausener Straße 11a
++  81379 München
++  Tel +49 89 32 19 77 80
++  Fax +49 89 32 19 77 89 
++  E-Mail brunni@netestate.de
++  https://www.netestate.de/
++
++  Sitz: München, HRB Nr.142452 (Handelsregister B München)
++  USt-IdNr. DE221033342
++  Geschäftsführer: Michael Brunnbauer, Franz Brunnbauer
++  Prokurist: Dipl. Kfm. (Univ.) Markus Hendel

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: reiserfs broke between 4.9.205 and 4.9.208

[Jeff Mahoney]

[-- Attachment #1.1: Type: text/plain, Size: 972 bytes --]

Hi Michael -

It looks like something must've gone sideways with the backport since
5.5-rc6 works as expected.  I'll dig into it a bit.

-Jeff

On 1/14/20 3:21 PM, Michael Brunnbauer wrote:
> 
> hi all,
> 
> is this been looked into? Do you need more information?
> 
> Regards,
> 
> Michael Brunnbauer
> 
> On Thu, Jan 09, 2020 at 01:30:41PM +0100, Michael Brunnbauer wrote:
>>
>> Hello Jan,
>>
>> On Thu, Jan 09, 2020 at 01:12:16PM +0100, Jan Kara wrote:
>>> Also Michael, I'd like to clarify: Does 'cp -a' return any error or is it
>>> just that the kernel is spewing these annoying warnings?  Because from the
>>> code reading I'd think that it is only the kernel spewing errors but
>>> userspace should be fine...
>>
>> Yes, 'cp -a' returns errors and files are owned by root instead of the correct
>> user after copying as root.
>>
>> Regards,
>>
>> Michael Brunnbauer


-- 
Jeff Mahoney
Director, SUSE Labs Data & Performance


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: reiserfs broke between 4.9.205 and 4.9.208

[Jeff Mahoney]

[-- Attachment #1.1: Type: text/plain, Size: 1452 bytes --]

Nevermind.  I just wasn't reproducing properly.  Jan's analysis is
right.  The -EOPNOTSUPP change is required so that we get the right
error when explicit xattr operations are performed on a file system
without them.  Prior to this change, we'd get -EOPNOTSUPP by sb->s_xattr
being NULL.

reiserfs_for_each_xattr needs to handle this the same way we already
handle -ENODATA.

-Jeff

On 1/15/20 12:03 PM, Jeff Mahoney wrote:
> Hi Michael -
> 
> It looks like something must've gone sideways with the backport since
> 5.5-rc6 works as expected.  I'll dig into it a bit.
> 
> -Jeff
> 
> On 1/14/20 3:21 PM, Michael Brunnbauer wrote:
>>
>> hi all,
>>
>> is this been looked into? Do you need more information?
>>
>> Regards,
>>
>> Michael Brunnbauer
>>
>> On Thu, Jan 09, 2020 at 01:30:41PM +0100, Michael Brunnbauer wrote:
>>>
>>> Hello Jan,
>>>
>>> On Thu, Jan 09, 2020 at 01:12:16PM +0100, Jan Kara wrote:
>>>> Also Michael, I'd like to clarify: Does 'cp -a' return any error or is it
>>>> just that the kernel is spewing these annoying warnings?  Because from the
>>>> code reading I'd think that it is only the kernel spewing errors but
>>>> userspace should be fine...
>>>
>>> Yes, 'cp -a' returns errors and files are owned by root instead of the correct
>>> user after copying as root.
>>>
>>> Regards,
>>>
>>> Michael Brunnbauer
> 
> 


-- 
Jeff Mahoney
Director, SUSE Labs Data & Performance


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: reiserfs broke between 4.9.205 and 4.9.208

[Jeff Mahoney]

[-- Attachment #1.1: Type: text/plain, Size: 2054 bytes --]

On 1/9/20 7:12 AM, Jan Kara wrote:
> 
> Hello,
> 
> On Wed 08-01-20 15:42:58, Randy Dunlap wrote:
>> On 1/8/20 11:36 AM, Michael Brunnbauer wrote:
>>> after upgrading from 4.9.205 to 4.9.208, I get errors on two different
>>> reiserfs filesystems when doing cp -a (the chown part seems to fail) and
>>> on other occasions:
>>>
>>>  kernel: REISERFS warning (device sda1): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)
>>>
>>>  kernel: REISERFS warning (device sdc1): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)
>>>
>>> This behaviour disappeared after a downgrade to 4.9.205.
>>>
>>> I understand there have been changes to the file system code but I'm not
>>> sure they affect reiserfs, e.g.
>>>
>>>  https://bugzilla.kernel.org/show_bug.cgi?id=205433
>>>
>>> Any Idea?
>>>
>>> Regards,
>>>
>>> Michael Brunnbauer
>>>
>>
>> Looks to me like 4.9.207 contains reiserfs changes.
>>
>> Adding CC's.
> 
> Looks like a regression from commit 60e4cf67a582 "reiserfs: fix extended
> attributes on the root directory". We are getting -EOPNOTSUPP from
> reiserfs_for_each_xattr() likely originally from open_xa_root(). Previously
> we were returning -ENODATA from there which error reiserfs_for_each_xattr()
> converted to 0. I don't understand reiserfs xattrs enough to quickly tell
> what should actually be happening after the Jeff's change - naively I'd
> think we should just silence the bogus warning in case of EOPNOTSUPP. Jeff,
> can you have a look?
> 
> Also Michael, I'd like to clarify: Does 'cp -a' return any error or is it
> just that the kernel is spewing these annoying warnings?  Because from the
> code reading I'd think that it is only the kernel spewing errors but
> userspace should be fine...

This error occurs when extended attributes are not enabled on the file
system *and* the module is not built with extended attributes enabled.
I've sent out the fix for it just now.

-Jeff

-- 
Jeff Mahoney
Director, SUSE Labs Data & Performance


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: reiserfs broke between 4.9.205 and 4.9.208

[Jeff Mahoney]

[-- Attachment #1.1: Type: text/plain, Size: 2711 bytes --]

On 1/20/20 10:03 AM, Byron Stanoszek wrote:
> On Wed, 15 Jan 2020, Jeff Mahoney wrote:
>> On 1/9/20 7:12 AM, Jan Kara wrote:
>>>
>>> Hello,
>>>
>>> On Wed 08-01-20 15:42:58, Randy Dunlap wrote:
>>>> On 1/8/20 11:36 AM, Michael Brunnbauer wrote:
>>>>> after upgrading from 4.9.205 to 4.9.208, I get errors on two different
>>>>> reiserfs filesystems when doing cp -a (the chown part seems to
>>>>> fail) and
>>>>> on other occasions:
>>>>>
>>>>>  kernel: REISERFS warning (device sda1): jdm-20004
>>>>> reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)
>>>>>
>>>>>  kernel: REISERFS warning (device sdc1): jdm-20004
>>>>> reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)
>>>>>
>>>>> This behaviour disappeared after a downgrade to 4.9.205.
>>>>>
>>>>> I understand there have been changes to the file system code but
>>>>> I'm not
>>>>> sure they affect reiserfs, e.g.
>>>>>
>>>>>  https://bugzilla.kernel.org/show_bug.cgi?id=205433
>>>>>
>>>>> Any Idea?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Michael Brunnbauer
>>>>>
>>>>
>>>> Looks to me like 4.9.207 contains reiserfs changes.
>>>>
>>>> Adding CC's.
>>>
>>> Looks like a regression from commit 60e4cf67a582 "reiserfs: fix extended
>>> attributes on the root directory". We are getting -EOPNOTSUPP from
>>> reiserfs_for_each_xattr() likely originally from open_xa_root().
>>> Previously
>>> we were returning -ENODATA from there which error
>>> reiserfs_for_each_xattr()
>>> converted to 0. I don't understand reiserfs xattrs enough to quickly
>>> tell
>>> what should actually be happening after the Jeff's change - naively I'd
>>> think we should just silence the bogus warning in case of EOPNOTSUPP.
>>> Jeff,
>>> can you have a look?
>>>
>>> Also Michael, I'd like to clarify: Does 'cp -a' return any error or
>>> is it
>>> just that the kernel is spewing these annoying warnings?  Because
>>> from the
>>> code reading I'd think that it is only the kernel spewing errors but
>>> userspace should be fine...
>>
>> This error occurs when extended attributes are not enabled on the file
>> system *and* the module is not built with extended attributes enabled.
>> I've sent out the fix for it just now.
>>
>> -Jeff
> 
> Hi Jeff,
> 
> Can you share the patch with us for testing? I haven't seen this hit
> mainline
> yet.

Sure.  I posted it to the reiserfs-devel list last week and Jan Kara
pulled it into his tree for submission to mainline.

It's in linux-next:

https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/fs/reiserfs?id=394440d469413fa9b74f88a11f144d76017221f2

-Jeff

-- 
Jeff Mahoney
Director, SUSE Labs Data & Performance


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: reiserfs broke between 4.9.205 and 4.9.208

[Byron Stanoszek]

On Wed, 15 Jan 2020, Jeff Mahoney wrote:
>On 1/9/20 7:12 AM, Jan Kara wrote:
>>
>> Hello,
>>
>> On Wed 08-01-20 15:42:58, Randy Dunlap wrote:
>>> On 1/8/20 11:36 AM, Michael Brunnbauer wrote:
>>>> after upgrading from 4.9.205 to 4.9.208, I get errors on two different
>>>> reiserfs filesystems when doing cp -a (the chown part seems to fail) and
>>>> on other occasions:
>>>>
>>>>  kernel: REISERFS warning (device sda1): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)
>>>>
>>>>  kernel: REISERFS warning (device sdc1): jdm-20004 reiserfs_delete_xattrs: Couldn't delete all xattrs (-95)
>>>>
>>>> This behaviour disappeared after a downgrade to 4.9.205.
>>>>
>>>> I understand there have been changes to the file system code but I'm not
>>>> sure they affect reiserfs, e.g.
>>>>
>>>>  https://bugzilla.kernel.org/show_bug.cgi?id=205433
>>>>
>>>> Any Idea?
>>>>
>>>> Regards,
>>>>
>>>> Michael Brunnbauer
>>>>
>>>
>>> Looks to me like 4.9.207 contains reiserfs changes.
>>>
>>> Adding CC's.
>>
>> Looks like a regression from commit 60e4cf67a582 "reiserfs: fix extended
>> attributes on the root directory". We are getting -EOPNOTSUPP from
>> reiserfs_for_each_xattr() likely originally from open_xa_root(). Previously
>> we were returning -ENODATA from there which error reiserfs_for_each_xattr()
>> converted to 0. I don't understand reiserfs xattrs enough to quickly tell
>> what should actually be happening after the Jeff's change - naively I'd
>> think we should just silence the bogus warning in case of EOPNOTSUPP. Jeff,
>> can you have a look?
>>
>> Also Michael, I'd like to clarify: Does 'cp -a' return any error or is it
>> just that the kernel is spewing these annoying warnings?  Because from the
>> code reading I'd think that it is only the kernel spewing errors but
>> userspace should be fine...
>
>This error occurs when extended attributes are not enabled on the file
>system *and* the module is not built with extended attributes enabled.
>I've sent out the fix for it just now.
>
>-Jeff

Hi Jeff,

Can you share the patch with us for testing? I haven't seen this hit mainline
yet.

Thanks,
  -Byron