[reiserfs-list] Re: [OpenAFS-devel] more on the 2.2.18pre17 SMPcpu
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
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 Neulinger EMail: firstname.lastname@example.org
University of Missouri - Rolla Phone: (573) 341-4841
CIS - Systems Programming Fax: (573) 341-4216