On Tue, Jul 12, 2005 at 09:31:35AM -0600, Patrick Walsh wrote:
> 	Unfortunately, lately we've been getting inconsistencies more routinely
> than before.  This morning I came in and found some inconsistencies that
> I couldn't fix.  Here's a sample transcript:
> 
> # cfs flushcache
> # service codaclient restart (this restarts venus and unloads and
> reloads the kernel module)
> # cd /path/to/inconsistent/object
> # ls -l savi.dl_
> lrwxr-xr-x    1 admin    65534          36 Jul 11 19:07 savi.dl_ ->
> @7f000001.00001c8c.00009470_at_director
> # cfs br savi.dl_
> savi.dl_ isn't inconsistent
> 
> 	But obviously it is.  The repair program gives the same sort of
> problem.  And the console log file shows this:

Actually it is probably the parent directory. When your client tries to
access the file, the server has to grab the parent directory to check
the ACL. But if the parent is inconsistent it returns EINCONS and the
client shows the file as being inconsistent.

The problem is that the callback that was sent to force directory
revalidation was lost or ignored because the directory was dirty, or
something has a reference to it and we can't turn it into a dangling
symlink.

I'm not yet sure how to fix this, I guess I could ignore the
inconsistency when checking the ACL, if there happens to be an
(unlikely) difference between the servers, some will perform the
operation and others might return permission denied. But since setacl
is fairly infrequent the servers should agree most of the time.

> 	Any ideas on 1) what might be causing this and 2) how to repair these
> files?

cfs fl on the parent directory should make the real conflict visible, as
long as there are no processes that have an active reference and are
keeping it pinned as a directory in the kernel.

Jan