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.britt...@dartmouth.edu 6-2085
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info

Reply via email to