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

Pranith Kumar Karampuri pkarampu at redhat.com
Sun May 18 17:48:13 UTC 2014


Sent the following patch to remove the special treatment of ENOTSUP here: http://review.gluster.org/7788

Pranith
----- Original Message -----
> From: "Kaleb KEITHLEY" <kkeithle at redhat.com>
> To: gluster-devel at gluster.org
> Sent: Tuesday, May 13, 2014 8:01:53 PM
> Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP for	setxattr
> 
> 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
> 
> 
> 
> 
> 
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
> 



More information about the Gluster-devel mailing list