[reiserfs-list] Re: [OpenAFS-devel] more on the 2.2.18pre17 SMPcpu hog/etc.
Mon, 4 Dec 2000 18:27:13 -0500 (EST)
On Tue, 5 Dec 2000, 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.
Um. No. This design has worked just fine on a variety of UNIX
filesystems for the past ~15 years, by opening files by inode number. The
only UNIX filesystems which can't do this operation efficiently are those
that were designed from scratch to have different characteristics (like
resierfs), or those that were imported from other OS's with different
> 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.
Not true. The memory cache uses an array of cache entries, each of which
contains a pointer to a separately-allocated data area. Instead of having
a large number of files, you have a large number of separately-allocated
memory blocks. It is also worth noting that the memcache uses a
completely separate set of backend cache operations than those used with a
> 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.
Also not true. The AFS kernel code _never_ creates inodes. If you set
the cache size on the fly, all you are doing is changing the maximum
number of blocks the cache can use -- the number of chunks does not
-- Jeffrey T. Hutzelman (N3NHS) <firstname.lastname@example.org>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA