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

Nathan Neulinger nneul@umr.edu
Sat, 02 Dec 2000 11:18:39 -0600

> Ok, the problem is that AFS is calling iget, so it probably needs special
> code to deal with reiserfs.
> For reiserfs to find an inode on disk, it needs the inode number of the
> file, and the packing locality.  This is usually (but not always) the inode
> number of the parent directory.  Calling iget is fine when the inode is
> already in memory, otherwise the reiserfs code goes into a very slow, very
> ugly search (the search_by_objectid call) to fill in the other 32 bits of
> information needed to find the file.

But here's the part that doesn't make sense - it doesn't do that on ANY
of the other machines on which I run afs + reiserfs. On most of the
other machines, with caches that are usually anywhere from 15,000 -
35,000 files on reiserfs partitions, it starts up in a few seconds. 

The only difference that I can think of is that my home machine has the
afscache as part of the root filesystem, and not on a dedicated
partition (i.e. it's own filesystem at top level, with nothing other
than afscache in it).

> So, can AFS store more information about the file in a filehandle of some
> kind?  If so, we can give you code to fill in the packing locality for iget.

I don't know. Whatever is done, it will have to remain 100% compatible
with ext2. 

The relevant code is at:


afsd/afsd.c: look for (call_syscall(AFSOP_CACHEINODE,...)

afs/afs_call.c: look for AFSOP_CACHEINODE  

afs/afs_dcache.c: look for the call to osi_UFSOpen in afs_InitCacheFile

afs/LINUX/osi_file.c: look for osi_UFSOpen - this is where the iget call

-- Nathan

Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
CIS - Systems Programming                Fax: (573) 341-4216