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

[Derek Atkins]

Harald Barth <haba@pdc.kth.se> writes:

> > 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.

I'm not convinced this is a design miss.. The cache manager needs to
walk the cache to see what's in it, and then it can random-access into
the cache at a later time.  This implies that it has to walk the
directory at the beginning, so it doesn't matter how long it takes to
walk it.  Subsequenty, it caches the inode number so it doesn't need
to go through the directory for future accesses.  So, indeed, I think
the current design is actually very clever.  The problem is that
reiserfs doesn't use the inode (by itself) to key into the filesystem
like pretty much every other FS in existence.

> Harald.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
       warlord@MIT.EDU                        PGP key available