Re: Proposed AFS '-type afsvmount' switch

[Steve Simmons]

On Tue, Feb 08, 2005 at 09:12:04PM +0000, James Youngman wrote:

> > I'm going to be hacking on findutils a bit to restore and extend some
> > of the AFS-specific features, 
> 
> Excellent news.  As a general principle I would like it if the
> features added for support of AFS could in principle be extended to
> work in a rational and similar way on systems/filesystems other than
> AFS.

Yes.

> Also, it would be best if compiling findutils with support for AFS
> didn't cause a routine degradation of performance unless you use a
> test which 'mentions' AFS.  That is, I don't really want there to be a
> significant performance penalty for AFS support if AFS is not actually
> in current use on a given machine.

The initial changes I plan on should be completely self-contained in
the sense that if the user has not asked for the AFS-specific feature,
the code should never be executed.  With respect to the running of
findutils, I specificly want to avoid having to make any contact with
AFS except such as might occur during any filesystem access, eg, find
traversing some part of an AFS tree.  The OS would of course contact
AFS to satisfy directory listings, etc, but find itself would do no
AFS calls unless an AFS-specific switch was present on the command line.

I've not dived into the code enough to see if/how various subtasks
are dispatched, but in general I'll simply follow whatever mechanism
is present already.  I did notice some dispatch tables and am comfortable
working with such.

> Circular filesystem loops can and do occur with other filesystems too
> (I'm not talking about symbolic links only).  GNU find detects these
> by remembering the device number and inode number of all parent
> directories (obtaining both from stat(2)).  The POSIX standard in fact
> requires that all implementations of find do this somehow.
> 
> Will testing with the device number and inode number also work for
> AFS?  If I mount the same volume in /x/foo and /x/foo/bar/quux, will
> it have the same value for st_dev and st_ino in both places?
> 
> Do AFS mount points end up in /etc/mtab or similar?

AFS mount point do not end up in /etc/mtab nor (as best I can tell
at this point) anywhere in the OS.  My experience with them as user
and sysadmin says that the volume name and optionally cell name are
stored in the directory in a manner similar to how symlinks work.
I'll be verifying this by reading the code shortly.

Current GNU find 'detects' circular loops in AFS and reports them
as excessively deep sets of symbolic links, but I need to expand
that testing and verify some details.  In particular, the error
message is misleading but I don't see how to give a more specific
one without invoking AFS-specific code.  One possible improvement
is to made the actual text of the message determined by #ifdef AFS,
but given that the string itself comes from errno.h and friends,
this doesn't seem worth the effort.

There is an unexpected performance different between AFS-enabled
and not-enabled 4.2.15.  When a circular volume mount is detected,
both report 'Number of symbolic links encountered during path name
traversal exceeds MAXSYMLINKS'.  The AFS-enabled version simply
stops at that point.  The non-enabled version acts as if it
pruned the tree at that point and continues.

> A similar thing is a requirement to find broken symlinks . . .

Yes, tho 'broken' AFS mounts aren't necessarily broken -- it
might merely mean that the particular server or cell is simply
unavailable.  Since the error types (and so much of the rest of
the filesystem handling) are different, I plan on making AFS volume
detection and reporting controlled by AFS-specific switches.  This
does put extra burden on the AFS admins/users to use those switches,
but it also means that performance isn't degraded unless the AFS
switches are used.  AFS protocol calls to remote or unreliable
cells can be *very* slow, and while they don't degrade system
performance significantly, they can have radical effects on wall-clock
run times.

> Volumes have names in other systems too.  It would be nice if the
> support would bear extension to work with other systems.  

I will keep this in mind.

> >    o  Pruning trees at volume mount points can prevent recursion.
> 
> The POSIX -xdev option is supposed to allow this.  It seems sensible
> to allow this to work for AFS too.

I agree, but would welcome some discussion on the topic.  In particular,
if -xdev also exclude AFS mounts, performance on AFS systems will suffer
greatly.  My first impulse is to wave my hands and say that AFS mounts
aren't devices, but that may not be consistant how find treats other
networked FS mounts.

> >    o  Ability to detect cell boundaries can prevent massive
> >       problems with network timouts, particularly if someone
> >       naively attempts to index /afs.
> 
> See also http://savannah.gnu.org/bugs/?func=detailitem&item_id=8599

Hmmm . . . yes, this idea has come up before, and has relevance for
AFS and NFS and probably others.  It's something to hold on to for
the longer term, tho - first I need to get in some of the AFS-specific
features.  Then we can think about distributed dbs.
-- 
"In my darker moments I consider creating the eeyore fan club with a theme
song by Leonard Cohen, logo by Edvard Munch and costumes by Tim Burton."
   -- anonymous, forwarded by Ellen.