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

[Harshavardhana]

http://review.gluster.com/#/c/7823/ - the fix here

On Thu, May 22, 2014 at 1:41 PM, Harshavardhana
<harsha at harshavardhana.net> 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 at redhat.com> 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 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
>>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> 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