[OpenAFS] AFS version of du

Richard Brittain Richard.Brittain@dartmouth.edu
Fri, 30 Apr 2010 12:44:07 -0400 (EDT)

On Fri, 30 Apr 2010, Steve Simmons wrote:

> On Apr 30, 2010, at 4:15 AM, Staffan H?m?l? wrote:
>> Is there a version of du that does not follow AFS mountpoints?
>> If I try to do a 'du -sh *' in a directory that has some AFS mountpoints it inevitably fails after some time. It also takes a lot of time when it has to look through things in mounted volumes (e.g. the backup volume that I have mounted in many places).
>> I've tried -P and -x to make it skip mount points, but it doesn't work (at least on CentOS 5 Linux).
> The short answer is that it might be coming coming, but it's going to be 
> a while. Here's the detailed scoop as I understand it, based on some old 
> mail exchanges I had with the findutils maintainer James Youngman and 
> discussion on the findutils mailing list.

This is very promising news.  I was about to start a new thread about 
problems with 'find', but since it is so closely linked with this I'll 
just jump in here.

Yesterday I was running 'find' and 'fs lsmount' across our cell to 
explicitly look for volume mountpoints, and got some very strange errors. 
On directories which exist and I had full access to, find would sometimes 
throw a big pile of errors like:
   find: ./users/a/: No such file or directory

- and obviously did not recurse into that directory.  It was acting like 
it read the directory entries but failed to later stat() them.  I blamed 
GNU find for a while, but then observed the same behaviour from Solaris 9 
and OSX.

This is definitely not a permission issue (l ACL but not r), but it does 
seem to be related to crossing mount points, since I have never seen an 
error running find inside a single volume.  I finally got a RHEL5 linux 
box to recurse my cell to the desired depth with no errors, but only as 
long as it was doing nothing else.  Running two 'find's immediately 
generated errors (RHEL5 current, OpenAFS 1.4.12).

My servers are a mix of 1.4.11 and 1.4.12 currently.

I discovered that one user had made a mount point for a different cell's 
root inside his home.  RHEL5/openafs 1.4.12 happily crossed over and 
starting searching the other cell, but I noticed that my other test system 
(RHEL4/openafs 1.4.11) didn't follow.  It would be _really_ nice if tools 
didn't follow mount points to other cells, if nothing else!

Richard Brittain,  Research Computing Group,
                    Kiewit Computing Services, 6224 Baker/Berry Library
                    Dartmouth College, Hanover NH 03755
Richard.Brittain@dartmouth.edu 6-2085