Re: [Gluster-devel] regarding special treatment of ENOTSUP for setxattr
- Original Message -
> From: "Pranith Kumar Karampuri"
> To: "Vijay Bellur"
> Cc: "Gluster Devel"
> 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"
> > To: "Harshavardhana"
> > Cc: "Gluster Devel"
> > 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"
> > > To: "Pranith Kumar Karampuri"
> > > Cc: "Kaleb KEITHLEY" , "Gluster Devel"
> > >
> > > 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
> > > 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)
> > > > {
> > > > longerror;
> > > > 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 intflags;
> > > > unsigned intmask;
> > > > 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
> > > > wrote:
> > > >> Sent the following patch to remove the special treatment of ENOTSUP
> > > >> here:
> > > >> http://review.gluster.org/7788
> > > >>
> > > >> Pranith
> > > >> - Original Message -
> > > >>> From: "Kaleb KEITHLEY"
> > > >>> To: gluster-devel@gluster.org
> > > >>> Sent: Tuesday, May 13, 2014 8:01:53 PM
> > > >>> Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP
> > > >>> for
> > > >>> setxattr
> > > >>>
> &
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.
Pranith
- Original Message -
> From: "Pranith Kumar Karampuri"
> To: "Harshavardhana"
> Cc: "Gluster Devel"
> 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"
> > To: "Pranith Kumar Karampuri"
> > Cc: "Kaleb KEITHLEY" , "Gluster Devel"
> >
> > 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
> > 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)
> > > {
> > > longerror;
> > > 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 intflags;
> > > unsigned intmask;
> > > 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
> > > wrote:
> > >> Sent the following patch to remove the special treatment of ENOTSUP
> > >> here:
> > >> http://review.gluster.org/7788
> > >>
> > >> Pranith
> > >> - Original Message -
> > >>> From: "Kaleb KEITHLEY"
> > >>> To: gluster-devel@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"
> > >>> >>> To: "Pranith Kumar Karampuri"
> > >>> >>> Cc: "Vijay Bellur" , gluster-devel@gluster.org,
> > >>> >>> "Anand Avati"
> > >>> >>> Sent: Wednesday, May 7, 2014 3:42:16 PM
> > >>> >>> Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP
> > >>> >>> for setxattr
> > >>> >>>
> > >>> >&g
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"
> To: "Pranith Kumar Karampuri"
> Cc: "Kaleb KEITHLEY" , "Gluster Devel"
>
> 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
> 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)
> > {
> > longerror;
> > 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 intflags;
> > unsigned intmask;
> > 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
> > wrote:
> >> Sent the following patch to remove the special treatment of ENOTSUP here:
> >> http://review.gluster.org/7788
> >>
> >> Pranith
> >> - Original Message -
> >>> From: "Kaleb KEITHLEY"
> >>> To: gluster-devel@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"
> >>> >>> To: "Pranith Kumar Karampuri"
> >>> >>> Cc: "Vijay Bellur" , gluster-devel@gluster.org,
> >>> >>> "Anand Avati"
> >>> >>> 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 b
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
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)
> {
> longerror;
> 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 intflags;
> unsigned intmask;
> 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
> wrote:
>> Sent the following patch to remove the special treatment of ENOTSUP here:
>> http://review.gluster.org/7788
>>
>> Pranith
>> ----- Original Message -
>>> From: "Kaleb KEITHLEY"
>>> To: gluster-devel@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"
>>> >>> To: "Pranith Kumar Karampuri"
>>> >>> Cc: "Vijay Bellur" , gluster-devel@gluster.org,
>>> >>> "Anand Avati"
>>> >>> 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
Re: [Gluster-devel] regarding special treatment of ENOTSUP for setxattr
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)
{
longerror;
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 intflags;
unsigned intmask;
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
wrote:
> Sent the following patch to remove the special treatment of ENOTSUP here:
> http://review.gluster.org/7788
>
> Pranith
> - Original Message -
>> From: "Kaleb KEITHLEY"
>> To: gluster-devel@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"
>> >>> To: "Pranith Kumar Karampuri"
>> >>> Cc: "Vijay Bellur" , gluster-devel@gluster.org,
>> >>> "Anand Avati"
>> >>> 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@gluster.org
>> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
>>
> ___
> Gluster-devel mailing list
> Gluster-devel@gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-devel
--
Religious confuse piety with mere ritual, the virtuous confuse
regulation with outcomes
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] regarding special treatment of ENOTSUP for setxattr
Sent the following patch to remove the special treatment of ENOTSUP here: http://review.gluster.org/7788 Pranith - Original Message - > From: "Kaleb KEITHLEY" > To: gluster-devel@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" > >>> To: "Pranith Kumar Karampuri" > >>> Cc: "Vijay Bellur" , gluster-devel@gluster.org, > >>> "Anand Avati" > >>> 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@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
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" To: "Pranith Kumar Karampuri" Cc: "Vijay Bellur" , gluster-devel@gluster.org, "Anand Avati" 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@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] regarding special treatment of ENOTSUP for setxattr
On 05/07/2014 03:44 PM, Pranith Kumar Karampuri wrote: - Original Message - From: "Raghavendra Gowdappa" To: "Pranith Kumar Karampuri" Cc: "Vijay Bellur" , gluster-devel@gluster.org, "Anand Avati" 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? Pranith - Original Message - From: "Pranith Kumar Karampuri" To: "Vijay Bellur" Cc: gluster-devel@gluster.org, "Anand Avati" Sent: Wednesday, 7 May, 2014 3:12:10 PM Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP for setxattr - Original Message - From: "Vijay Bellur" To: "Pranith Kumar Karampuri" , "Anand Avati" Cc: gluster-devel@gluster.org Sent: Tuesday, May 6, 2014 7:16:12 PM Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP for setxattr On 05/06/2014 01:07 PM, Pranith Kumar Karampuri wrote: hi, Why is there occasional logging for ENOTSUP errno when setxattr fails? In the absence of occasional logging, the log files would be flooded with this message every time there is a setxattr() call. How to know which keys are failing setxattr with ENOTSUPP if it is not logged when the key keeps changing? Pranith -Vijay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel Checkout http://review.gluster.com/#/c/3140/ & the associated BZ. Thanks Naga ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] regarding special treatment of ENOTSUP for setxattr
On 05/07/2014 03:44 PM, Pranith Kumar Karampuri wrote: - Original Message - From: "Raghavendra Gowdappa" To: "Pranith Kumar Karampuri" Cc: "Vijay Bellur" , gluster-devel@gluster.org, "Anand Avati" 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? Pranith Have we look at the low level log files and/or kernel code to see when we would get an error back? I wonder if we have bumped into a limit somewhere? Ric ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] regarding special treatment of ENOTSUP for setxattr
- Original Message - > From: "Raghavendra Gowdappa" > To: "Pranith Kumar Karampuri" > Cc: "Vijay Bellur" , gluster-devel@gluster.org, "Anand > Avati" > 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? Pranith > > - Original Message - > > From: "Pranith Kumar Karampuri" > > To: "Vijay Bellur" > > Cc: gluster-devel@gluster.org, "Anand Avati" > > Sent: Wednesday, 7 May, 2014 3:12:10 PM > > Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP for > > setxattr > > > > > > > > - Original Message - > > > From: "Vijay Bellur" > > > To: "Pranith Kumar Karampuri" , "Anand Avati" > > > > > > Cc: gluster-devel@gluster.org > > > Sent: Tuesday, May 6, 2014 7:16:12 PM > > > Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP for > > > setxattr > > > > > > On 05/06/2014 01:07 PM, Pranith Kumar Karampuri wrote: > > > > hi, > > > >Why is there occasional logging for ENOTSUP errno when setxattr > > > >fails? > > > > > > > > > > In the absence of occasional logging, the log files would be flooded > > > with this message every time there is a setxattr() call. > > > > How to know which keys are failing setxattr with ENOTSUPP if it is not > > logged > > when the key keeps changing? > > > > Pranith > > > > > > -Vijay > > > > > > > > ___ > > Gluster-devel mailing list > > Gluster-devel@gluster.org > > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
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). - Original Message - > From: "Pranith Kumar Karampuri" > To: "Vijay Bellur" > Cc: gluster-devel@gluster.org, "Anand Avati" > Sent: Wednesday, 7 May, 2014 3:12:10 PM > Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP for > setxattr > > > > - Original Message - > > From: "Vijay Bellur" > > To: "Pranith Kumar Karampuri" , "Anand Avati" > > > > Cc: gluster-devel@gluster.org > > Sent: Tuesday, May 6, 2014 7:16:12 PM > > Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP for > > setxattr > > > > On 05/06/2014 01:07 PM, Pranith Kumar Karampuri wrote: > > > hi, > > >Why is there occasional logging for ENOTSUP errno when setxattr fails? > > > > > > > In the absence of occasional logging, the log files would be flooded > > with this message every time there is a setxattr() call. > > How to know which keys are failing setxattr with ENOTSUPP if it is not logged > when the key keeps changing? > > Pranith > > > > -Vijay > > > > > ___ > Gluster-devel mailing list > Gluster-devel@gluster.org > http://supercolony.gluster.org/mailman/listinfo/gluster-devel > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] regarding special treatment of ENOTSUP for setxattr
- Original Message - > From: "Vijay Bellur" > To: "Pranith Kumar Karampuri" , "Anand Avati" > > Cc: gluster-devel@gluster.org > Sent: Tuesday, May 6, 2014 7:16:12 PM > Subject: Re: [Gluster-devel] regarding special treatment of ENOTSUP for > setxattr > > On 05/06/2014 01:07 PM, Pranith Kumar Karampuri wrote: > > hi, > >Why is there occasional logging for ENOTSUP errno when setxattr fails? > > > > In the absence of occasional logging, the log files would be flooded > with this message every time there is a setxattr() call. How to know which keys are failing setxattr with ENOTSUPP if it is not logged when the key keeps changing? Pranith > > -Vijay > > ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] regarding special treatment of ENOTSUP for setxattr
On Tue, May 6, 2014 at 12:37 AM, Pranith Kumar Karampuri wrote: > hi, > Why is there occasional logging for ENOTSUP errno when setxattr fails? > Do you really have xattr support? why is it logging in the first place? - it shouldn't ? -- Religious confuse piety with mere ritual, the virtuous confuse regulation with outcomes ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
Re: [Gluster-devel] regarding special treatment of ENOTSUP for setxattr
On 05/06/2014 01:07 PM, Pranith Kumar Karampuri wrote: hi, Why is there occasional logging for ENOTSUP errno when setxattr fails? In the absence of occasional logging, the log files would be flooded with this message every time there is a setxattr() call. -Vijay ___ Gluster-devel mailing list Gluster-devel@gluster.org http://supercolony.gluster.org/mailman/listinfo/gluster-devel
