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.
