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

Xuan Baldauf xuan--reiserfs@baldauf.org
Tue, 05 Dec 2000 02:00:51 +0100


Derek Atkins wrote:

> Harald Barth <haba@pdc.kth.se> writes:
>
> > > Unfortunately, the AFS cache does not meet those conditions.  The c=
ache 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

I do not agree. AFAIK a filesystem is allowed to move its files around. S=
o just
imagine that real locations of files data and metadata are moving all the=
 time. (A
filesystem must be allowed to repack its data, for resizing or defragment=
ation for
example.) The way to catch a filename|directory entry (which has its file
associated) is to use that filename. The way to catch just the file is to=
 use a
fd. If you want to catch the file for a long time independent of its name=
 and you
think that fds are too expensive, you better create a (hard) link. Anythi=
ng else
is using filesystem internals. (A file is defined to be reachable within =
a
filesystem if and only if the sum of its link count and its open count is=
 greater
than 0. The link count is the number of directory entries a file is refer=
enced by,
the open count is the number of times a file is opened.)

What you could do, if your original filename does not change, is to ask t=
he
filesystem for a hint to be passed later back to the filesystem to find t=
he file
more quickly than by name. But as usual with hints, the hint may fail, so=
 you
cannot ommit the filename of the file you mentioned.

Xu=E2n.