|
From: | Brent A Nelson |
Subject: | Re: [Gluster-devel] fchmod glitch in 1.4 tla? |
Date: | Wed, 23 Jul 2008 17:47:40 -0400 (EDT) |
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, BrentPS 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.
[Prev in Thread] | Current Thread | [Next in Thread] |