[reiserfs-list] Re: [OpenAFS-devel] more on the 2.2.18pre17 SMPcpu hog/etc.

[Jeffrey Hutzelman]

On Tue, 5 Dec 2000, Andi Kleen wrote:

> reiserfs is one of the file systems that does not care about big
> directories, it was designed for them.  The cache files have regular
> names, so if everything else fail you could just compute a unique number
> from the cache file name in user space, pass it in as inode and convert
> it back to the filename and open it using filp_open().

If this is true, then we're set.  IIRC, the MacOS X port already opens
cache files by name on HFS+ (but not on UFS), because it turns out that
HFS's indexing structure makes opening files very efficient if you know
the filename and parent dirid, and not so efficient if all you know is
the file's fileid.  If reiserfs has similar behaviour, then we can treat
it in a similar fashion.

> Actually with the efficient dcache in 2.2+ I suspect that method could
> be used unconditionally on Linux for all file systems without much if
> any slowdown.  As long as the dentries stay cached there is no directory
> walking overhead even on filesystem with not-so-well scaling directories
> like ext2. 

But I don't think you want to keep 32K+ dentries all the time, or assume
that they will stay in the cache.

> BTW, do you have plans to move to an external vnode for AFS? the 
> copied inode structure looks very fragile and has e.g. caused problems
> with the suse kernel (which has two fields more than a normal linux 2.2
> inode)

It's not as fragile as you might think.  The inode structure doesn't
change all that frequently, and using symbol versions catches it when
it does change.  Unfortunately, far too many people use AFS modules
without symbol versions.  I'm hoping that will begin to change.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA