Please review http://review.gluster.com/7788 submitted to remove the filtering
of that error.
Pranith
- Original Message -
From: Harshavardhana har...@harshavardhana.net
To: Pranith Kumar Karampuri pkara...@redhat.com
Cc: Kaleb KEITHLEY kkeit...@redhat.com, Gluster Devel
gluster-devel@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
har...@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)
{
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
pkara...@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 kkeit...@redhat.com
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 rgowd...@redhat.com
To: Pranith Kumar Karampuri pkara...@redhat.com
Cc: Vijay Bellur vbel...@redhat.com, gluster-devel@gluster.org,
Anand Avati aav...@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@gluster.org
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
___