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

[Jeffrey Hutzelman]

On Tue, 5 Dec 2000, Hans Reiser wrote:

> Harald Barth wrote:
> > 
> > > Unfortunately, the AFS cache does not meet those conditions.  The cache is
> > > a single directory that may have tens of thousands of files in it.
> > 
> > This is a design miss of the AFS cache which will give problems for
> > almost all flavours of *i*x file systems. It can only win by a change.
> > A change can go in two directions: Order the files in some directory
> > tree with some smart structure or give up the files approach and use
> > one big file. When using -memcache, the whole cache is one big chunk
> > of data, too. Another pain is this bad habit of creating all the
> > inodes at boot. If I start with a really small cache and later
> > increase the cache size on the fly, inodes are created without
> > blocking cache operations for minutes. So why the wait at boot? This
> > feature seems to be wanted by more than a few.
> > 
> > Harald.
> 
> afs probably should use something like the raw I/O interface we wrote
> for squid.  It has no need for a local filesystem directory, yes?  A
> name present in the filesystem directory is just overhead, yes or no? 
> Files without local FS names are what it really wants? 

Yes and no.  In normal operation, the cache manager has no need for
filenames - it just wants a bunch of files that it can open at will,
without lots of overhead.  However, it turns out to be useful for
debugging to have physical files on disk with names that allow them to be
accessed using normal tools.

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