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

[Andi Kleen]

On Mon, Dec 04, 2000 at 10:02:06AM -0500, Derek Atkins wrote:
> Chris Mason <mason@suse.com> writes:
> 
> > You are very likely to hit problems under load, regardless of how much
> > memory the system has.  When you say the Cache files are opened as needed,
> > do you mean there is no pratical way for userspace to always open/stat them
> > before the kernel opens them?
> 
> True, I didn't realize at the time that even on huge-memory machines,
> the number of inodes caches is still defaulting to 16k.  Ouch.  So,
> yes, with large AFS caches this will certainly be a problem.

inode cache is just the slave of the dcache and dcache is sized based on
memory in 2.4 (and in some 2.2 based kernels). As long as the dentry exists
the inode exists too. 

> This would certainly fix the 'number of inodes' problem.  Then we have
> the problem that the kernel needs to be able to re-open the file at a
> later date.  For this particular problem, we would need to cache
> whatever magic is needed in order to re-open the file quickly.
> Unfortunately, this sounds like it might be very filesystem specific
> (which is a poor design).  I need something that I can do through the
> standard VFS interface that will work for (practically) any Linux
> filesystem.  Currently this is implemented as iget() and then
> f_ops->f_open().  I could _try_ to cache additional information at
> this time, but I would certainly prefer to remain filesystem agnostic.

For NFS we were using hacks by adding new inode/superblock operations (not
integrated) Hopefully 2.5 will switch to 64bit inodes, which are needed
for other file systems too.

The more efficient and Linux 2.2 conform way would be to cache pointers to 
dentries though -- that would avoid the problem (because it keeps the inode 
in core) and is as fast. It probably needs some changes in the kernel
module though, because dentries need to be dput() when freed. Since 2.2
the Linux VFS is really dentry based, not inode based. Keeping the dentry
around is equivalent to keeping the file name, just much faster and it
cannot go away. You would pass in file names from user space and the
kernel module would lookup the dentries and cache that.




> Question: Why doesn't reiserfs use the inode number as the 'magic'
> number?  (No need to answer this; I really don't care about the design
> decisions made for reiserfs).

It does, but it is not enough as a key. It needs another 32bit value to
find the right place on disk. 



-Andi