Sent the following patch to remove the special treatment of ENOTSUP here: http://review.gluster.org/7788 Pranith ----- Original Message ----- > From: "Kaleb KEITHLEY" <kkeithle@xxxxxxxxxx> > To: gluster-devel@xxxxxxxxxxx > Sent: Tuesday, May 13, 2014 8:01:53 PM > Subject: Re: 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@xxxxxxxxxx> > >>> To: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > >>> Cc: "Vijay Bellur" <vbellur@xxxxxxxxxx>, gluster-devel@xxxxxxxxxxx, > >>> "Anand Avati" <aavati@xxxxxxxxxx> > >>> Sent: Wednesday, May 7, 2014 3:42:16 PM > >>> Subject: Re: 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@xxxxxxxxxxx > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
