[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
--
Richard Brittain, Research Computing Group,
Kiewit Computing Services, 6224 Baker/Berry Library
Dartmouth College, Hanover NH 03755
Richard.Brittain@dartmouth.edu 6-2085