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

[Chris Mason]

On Saturday, December 02, 2000 15:33:58 -0500 Derek Atkins
<warlord@MIT.EDU> wrote:

> I don't know anything about reiserfs, but I can explain what AFS is
> doing.  Basically, the afsd user-space process does an opendir() on
> the cache directory.  Then it iterates through the files looking for
> the cache files (they are all numbered, and the cachefile number is
> stored in the filename).  For each cache file, it stores the inode
> number (obtained from dirp->d_ino from readdir()) associated that that
> cache file number (obtained from dirp->d_name).
> 
> Later, the afsd user-space calls into the kernel, iterating through
> the cachefiles.  For each cachefile, it calls into the kernel with the
> inode number which is obtained as described in the previous paragraph.
> 
> The current interface does not have room for any other information to
> be passed along to the kernel.  Granted, we could change that.
> However, we would need to find the packing locality from user-space in
> order to pass it down into kernel space.  Is the packing locality
> available through the dirent structure?  If so, what structure member
> do I use?
> 

Good point, isn't an easy way to get it in userspace right now.

> Alternatively, I suppose we could perform an 'open' or a 'stat' of the
> cache file from user-space (using the filename) in order to pull the
> file into the kernel inode cache before passing the information along
> to the kernel.  That might be a more portable way of doing it,
> assuming a 'stat()' is sufficient to bring the inode into kernel cache
> so that iget() can easily grab it.
> 
> Chris, would a stat() be sufficient to bring inode into the cache and
> bypass the slow lookup?  (I'm going to assume that there is enough
> kernel memory to cache all the cacheinodes).
> 

It will probably work.  But under load, there is still a window for the
inode to leave the cache.  If userspace had the file open while the iget
was going on, you would know for sure the inode was in cache.

If you could pass the filename to the kernel, and have the kernel use the
name, it would probably be cleaner.  That would work on all the new
filesystems (GFS and XFS can use 64 bit inode numbers as well).

-chris