----- Original Message ----- > From: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > To: "Vijay Bellur" <vbellur@xxxxxxxxxx> > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > Sent: Wednesday, May 28, 2014 4:16:32 PM > Subject: Re: regarding special treatment of ENOTSUP for setxattr > > Vijay, > Could you please merge http://review.gluster.com/7788 if there are no more > concerns. Gentle reminder. Pranith. > > Pranith > ----- Original Message ----- > > From: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > > To: "Harshavardhana" <harsha@xxxxxxxxxxxxxxxxxx> > > Cc: "Gluster Devel" <gluster-devel@xxxxxxxxxxx> > > Sent: Monday, May 26, 2014 1:18:18 PM > > Subject: Re: regarding special treatment of ENOTSUP for > > setxattr > > > > Please review http://review.gluster.com/7788 submitted to remove the > > filtering of that error. > > > > Pranith > > ----- Original Message ----- > > > From: "Harshavardhana" <harsha@xxxxxxxxxxxxxxxxxx> > > > To: "Pranith Kumar Karampuri" <pkarampu@xxxxxxxxxx> > > > Cc: "Kaleb KEITHLEY" <kkeithle@xxxxxxxxxx>, "Gluster Devel" > > > <gluster-devel@xxxxxxxxxxx> > > > Sent: Friday, May 23, 2014 2:12:02 AM > > > Subject: Re: regarding special treatment of ENOTSUP for > > > setxattr > > > > > > http://review.gluster.com/#/c/7823/ - the fix here > > > > > > On Thu, May 22, 2014 at 1:41 PM, Harshavardhana > > > <harsha@xxxxxxxxxxxxxxxxxx> wrote: > > > > Here are the important locations in the XFS tree coming from 2.6.32 > > > > branch > > > > > > > > STATIC int > > > > xfs_set_acl(struct inode *inode, int type, struct posix_acl *acl) > > > > { > > > > struct xfs_inode *ip = XFS_I(inode); > > > > unsigned char *ea_name; > > > > int error; > > > > > > > > if (S_ISLNK(inode->i_mode)) ----------------> I would > > > > generally think this is the issue. > > > > return -EOPNOTSUPP; > > > > > > > > STATIC long > > > > xfs_vn_fallocate( > > > > struct inode *inode, > > > > int mode, > > > > loff_t offset, > > > > loff_t len) > > > > { > > > > long error; > > > > loff_t new_size = 0; > > > > xfs_flock64_t bf; > > > > xfs_inode_t *ip = XFS_I(inode); > > > > int cmd = XFS_IOC_RESVSP; > > > > int attr_flags = XFS_ATTR_NOLOCK; > > > > > > > > if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE)) > > > > return -EOPNOTSUPP; > > > > > > > > STATIC int > > > > xfs_ioc_setxflags( > > > > xfs_inode_t *ip, > > > > struct file *filp, > > > > void __user *arg) > > > > { > > > > struct fsxattr fa; > > > > unsigned int flags; > > > > unsigned int mask; > > > > int error; > > > > > > > > if (copy_from_user(&flags, arg, sizeof(flags))) > > > > return -EFAULT; > > > > > > > > if (flags & ~(FS_IMMUTABLE_FL | FS_APPEND_FL | \ > > > > FS_NOATIME_FL | FS_NODUMP_FL | \ > > > > FS_SYNC_FL)) > > > > return -EOPNOTSUPP; > > > > > > > > Perhaps some sort of system level acl's are being propagated by us > > > > over symlinks() ? - perhaps this is the related to the same issue of > > > > following symlinks? > > > > > > > > On Sun, May 18, 2014 at 10:48 AM, Pranith Kumar Karampuri > > > > <pkarampu@xxxxxxxxxx> wrote: > > > >> 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 > > > > > > > > > > > > > > > > -- > > > > Religious confuse piety with mere ritual, the virtuous confuse > > > > regulation with outcomes > > > > > > > > > > > > -- > > > Religious confuse piety with mere ritual, the virtuous confuse > > > regulation with outcomes > > > > > _______________________________________________ > > 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 > _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://supercolony.gluster.org/mailman/listinfo/gluster-devel
