From: Byron Stanoszek <gandalf@winds.org>
To: jeffm@suse.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: reiserfs broke between 4.9.205 and 4.9.208
Date: Mon, 20 Jan 2020 10:03:27 -0500 (EST) [thread overview]
Message-ID: <alpine.LNX.2.21.1.2001200956220.14639@winds.org> (raw)
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
next reply other threads:[~2020-01-20 15:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-20 15:03 Byron Stanoszek [this message]
2020-01-20 16:20 ` Jeff Mahoney
-- strict thread matches above, loose matches on Subject: below --
2020-01-08 19:36 Michael Brunnbauer
2020-01-08 23:42 ` Randy Dunlap
2020-01-09 12:12 ` Jan Kara
2020-01-09 12:30 ` Michael Brunnbauer
2020-01-14 20:21 ` Michael Brunnbauer
2020-01-15 17:03 ` Jeff Mahoney
2020-01-15 17:39 ` Jeff Mahoney
2020-01-15 18:02 ` Jeff Mahoney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.21.1.2001200956220.14639@winds.org \
--to=gandalf@winds.org \
--cc=jeffm@suse.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®