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

[Jeffrey Altman]

James Youngman wrote:

So here you see that with /mnt/test/1 mounted, the link count of
/mnt/test is 3.   However, this link count is at 3 because with
/mnt/test/1 UNmounted, there is still a directory /mnt/test/1 (i.e.
the mount point) and its ".." entry contributes 1 toward the link
count of /mnt/test.

That would be true in the case of mounting the AFS file system
on top of the /afs directory.

 So, to a program like find, there are effectively two kinds of
 subdirectories -- those that are included in the link count and those that
 are not.

That's not generally true for the reason illustrated above, but I'll
assume your statement was about AFS specifically.

Correct.

You can't tell in advance which kind you'll see, so a heuristic
 like checking to see if the rule applies to the first directory you
 examine, which probably works fairly well for other filesystems, won't work
 with AFS.

So is it the case that I can mount an AFS filesystem at
/afs/mumble/foo/bar without there previously existing a directory
/afs/mumble/foo?

In this case we are not discussing the mounting of a file system but


  /afs/athena.mit.edu -> athena.mit.edu#root.cell.

or the equivalent using the file ids and types of the objects

  Mountpoint (536870921.2.2428) -> Volume Root Directory (536871418.1.1)

where the file id consists of (volume,vnode,unique) and where the
volume ids correspond to

  536870921 = athena.mit.edu:root.afs.readonly
  536871418 = athena.mit.edu:root.cell.readonly

the mounting of a volume via the use of an AFS mount point which is not a directory but is more reasonably thought of as a special symlink.

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?

Is it feasible for example to assume that directories not
(canonically) beginning with /afs/ (or matching the regex ///+afs/)
simply cannot be on an AFS filesystem?

The AFS file system can be mounted on any directory and there are
some well known organizations that do mount the file system elsewhere
or even in more than one place in the file system tree.

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.

smime.p7s
Description: S/MIME Cryptographic Signature