Re: [Gluster-devel] fchmod glitch in 1.4 tla?

[Brent A Nelson]

On Wed, 23 Jul 2008, Amar S. Tumballi wrote:

> Brent,
> When you say 'error is gone' you are telling about fchmod error? or the
> setxattr logs?

Both, or so I thought.  But after doing a much bigger cp -a (/usr, rather 
than just a single file), I still eventually hit what appears to be the 
fchmod error, even with acl support, although it is much less common (and 
doesn't seem to be accompanied by glusterfs.log entries).

> A general rule on GNU/Linux system is, xattrs  supports only
>
> "user.<anything>", "trusted.<anything>" and "system.<anything>", as key. and
> with noacl, the "system.posix_acl_default" and "system.posix_acl_access"
> keys too return EOPNOTSUP errno. Hence the log in afr_setxattr. (Actually
> whenever this particular errno is returned to application, they neglect it,
> and proceed, so user won't know about this). The right fix is to correct the
> log entry for afr, not to show up if the errno is EOPNOTSUP. (which is done
> in other places like unify, fuse, and posix). So, this error msg is
> harmless.
>
> I am concerned about the EIO for fchmod, is it reprodicible with noacl flag
> set for backend fs?  (sorry for me not testing atm, my test nodes are down
> as of now). So, I can have the right fix for it not before tomorrow.

With noacl, I can produce the error with a "cp -a" of a single file, no 
problem (100%, so far).  With acl, it apparently still occurs, but it's 
much less common (probably a different trigger).

Thanks,

Brent

PS With acl support enabled, I do still hit the problem of cp -a not 
setting directory permissions, as before, so one probably should not run 
this way until ACLs are truly supported by GlusterFS.