[Gluster-devel] regarding special treatment of ENOTSUP for setxattr
Pranith Kumar Karampuri
pkarampu at redhat.com
Fri May 30 13:47:56 UTC 2014
----- Original Message -----
> From: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
> To: "Vijay Bellur" <vbellur at redhat.com>
> Cc: "Gluster Devel" <gluster-devel at gluster.org>
> Sent: Wednesday, May 28, 2014 4:16:32 PM
> Subject: Re: [Gluster-devel] 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 at redhat.com>
> > To: "Harshavardhana" <harsha at harshavardhana.net>
> > Cc: "Gluster Devel" <gluster-devel at gluster.org>
> > Sent: Monday, May 26, 2014 1:18:18 PM
> > Subject: Re: [Gluster-devel] 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 at harshavardhana.net>
> > > To: "Pranith Kumar Karampuri" <pkarampu at redhat.com>
> > > Cc: "Kaleb KEITHLEY" <kkeithle at redhat.com>, "Gluster Devel"
> > > <gluster-devel at gluster.org>
> > > Sent: Friday, May 23, 2014 2:12:02 AM
> > > Subject: Re: [Gluster-devel] 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 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
> > >
> > _______________________________________________
> > 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
>
More information about the Gluster-devel
mailing list