Bug#143111: [OpenAFS-devel] Testing GNU findutils on AFS.... please!

James Youngman jay@gnu.org
Mon, 5 May 2008 13:05:59 +0100


On Tue, Apr 8, 2008 at 12:19 AM, Jeffrey Altman
<jaltman@secure-endpoints.com> wrote:

> > At the moment, find (oldfind in 4.2.x and 4.3.x) relies on examining
> > the results of stat(2) to figure out if it should turn off the leaf
> > optimisation.  It makes this determination for every directory it
> > searches.   Supposing find knows that AFS may be in use somewhere on
> > the system, what is the highest performance way of determining if the
> > link-count assumption will hold immediately within that directory?
> >
>
>  Are you willing to attempt to try to perform an AFS pioctl call
>  to verify if the path is in AFS?

Speculatively for every directory on every system, no.   Once we are
known to be inside an AFS filesystem, yes.  The principle here being
that correctness trumps performance but people who don't use a feature
should not be expected to pay the performance cost of its use
elsewhere, as far as possible.

As far as I understand your earlier replies, I should be able to
notice the st_dev value change when I enter the AFS filesystem, and
that will allow me to decide to turn off the leaf optimisation for all
directories below it.  This would work, I think, except in the case of
-L which turns off the leaf optimisation anyway.

It occurs to me to ask something else though.  Is possible for there
to be any kind of infinite cycle in an AFS directory hierarchy?
With regular Unix filesystems we rely on the uniqueness of the
{st_dev,st_ino} combination; if we see the same value pair twice under
one startpoint, we conclude there is a loop.  Will this method work
for AFS?


> > Now that I think about it, it would also be helpful to know what
> > common Linux AFS clients put in struct dirent.d_type for AFS
> > filesystem objects (files, directories, ...).  How about other Unix
> > systems which support both AFS and d_type?  I also understand that AFS
> > ACLs can sometimes allow readddir() to return a directory entry
> > without it being possible to lstat(2) said directory item.  Is this
> > the case?   What goes into d_type for such items?
> >
>
>  I will let someone else answer this.

Nobody has, though, yet...

James.