[Gluster-devel] regarding special treatment of ENOTSUP for setxattr

[Kaleb KEITHLEY]

On 05/13/2014 08:00 AM, Nagaprasad Sathyanarayana wrote:
> On 05/07/2014 03:44 PM, Pranith Kumar Karampuri wrote:
>>
>> ----- Original Message -----
>>> From: "Raghavendra Gowdappa" <rgowdapp at redhat.com>
>>> To: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
>>> Cc: "Vijay Bellur" <vbellur at redhat.com>, gluster-devel at gluster.org,
>>> "Anand Avati" <aavati at redhat.com>
>>> Sent: Wednesday, May 7, 2014 3:42:16 PM
>>> Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP
>>> for setxattr
>>>
>>> I think with "repetitive log message suppression" patch being merged, we
>>> don't really need gf_log_occasionally (except if they are logged in
>>> DEBUG or
>>> TRACE levels).
>> That definitely helps. But still, setxattr calls are not supposed to
>> fail with ENOTSUP on FS where we support gluster. If there are special
>> keys which fail with ENOTSUPP, we can conditionally log setxattr
>> failures only when the key is something new?

I know this is about EOPNOTSUPP (a.k.a. ENOTSUPP) returned by 
setxattr(2) for legitimate attrs.

But I can't help but wondering if this isn't related to other bugs we've 
had with, e.g., lgetxattr(2) called on invalid xattrs?

E.g. see https://bugzilla.redhat.com/show_bug.cgi?id=765202. We have a 
hack where xlators communicate with each other by getting (and setting?) 
invalid xattrs; the posix xlator has logic to filter out  invalid 
xattrs, but due to bugs this hasn't always worked perfectly.

It would be interesting to know which xattrs are getting errors and on 
which fs types.

FWIW, in a quick perusal of a fairly recent (3.14.3) kernel, in xfs 
there are only six places where EOPNOTSUPP is returned, none of them 
related to xattrs. In ext[34] EOPNOTSUPP can be returned if the 
user_xattr option is not enabled (enabled by default in ext4.) And in 
the higher level vfs xattr code there are many places where EOPNOTSUPP 
_might_ be returned, primarily only if subordinate function calls aren't 
invoked which would clear the default or return a different error.

--

Kaleb