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. _______________________________________________ Bug-findutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-findutils
