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
