Re: Proposed AFS '-type afsvmount' switch

[James Youngman]

On Tue, Feb 08, 2005 at 01:58:37PM -0500, Steve Simmons 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.

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.

> Some general background on where AFS is an uncomfortable fit for find
> is appropriate here.  AFS permits or promotes a number of actions which
> are pretty foreign or non-existant in UNIX file systems:
> 
>    o  Unprivileged users can attach and detatch volumes at will
>       This means users can and do create circular mount trees.
>       Thus find may have to deal with issues in AFS trees that
>       don't occur in UNIX file system, and one cannot depend on
>       the sysadmin to have done the rational thing.

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?

>    o  A volume need not exist to be mounted.  A user can mount
>       an arbitrary volume name onto a directory, and the mount
>       point is created.  Errors occur when you try to traverse
>       it, and must be handled in some rational way.  One useful
>       find function would be to find all non-existant volume
>       mounts in a tree.

A similar thing is a requirement to find broken symlinks, which you
can do like this:-

 find . -type l -xtype l -print

>    o  Volumes have names, and names have meanings.  One may wish
>       to include or exclude a class of volumes based on the name
>       (or a regexp, I suppose).  Backup volume names end in
>       .backup, as a simple example.  But it might also be useful
>       to find only files which exist in 'user.*' volumes, or
>       in some departments tree.

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

>    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.

>    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

Regards,
James.