[OpenAFS-devel] RE: fsck

[Bill Zumach]

> Because the directory lookup overhead on most UNIX filesystems is quite
> high.  The result is that a server that accesses its data through links in
> the filesystem is considerably slower than one that accesses them by inode
> number.  IIRC, ext2 is better about this than most systems, but it's still
> not as good as being able to do lookups by number.

Lookup is not so much of a problem as file creation. On file systems which
do orderly meta-data updates (pretty much anyone other than ext2), creating
a file involves syncing the new inode as well as the directoty to disk. Even
a journalling file system occurs some of this overhead if there are a lot of
file creates going on, untar'ing a directory tree, for example.

Lookups should be pretty good on most filesystems. On the other hand, clones
are much faster using the namei interface (the one AFS uses for Linux and
Windows NT), because there is a file which contains the reference counts on
the AFS files. Using the inode interface, each inode for an AFS file needs
to be modified during a clone. (Note: by "reference count" I mean the number
of volumes which contain a given file).

>   When the
> through-the-filesystem approach is used, this metadata must be stored in
> an index file somewhere else in the filesystem 
Actually, the namei interface encodes this information in the file names.
Only the reference counts mentioned above are stored in a file and that 
information can be reconstructed.

SGI's XFS appearred to give reasonable performance using a very slight variant
of this namei interface. It might be interesting to see how it performs on
Linux, ReiserFS too for that matter.


Bill Zumach
Fringent Technologies, Inc.
(the one AFS uses on Linux and Windows NT), the clone operation is