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

[Chris Mason]

On Sunday, December 03, 2000 18:34:45 -0500 Jeffrey Hutzelman
<jhutz@cmu.edu> wrote:

> On 3 Dec 2000, Derek Atkins wrote:
> 
>> Hans Reiser <reiser@namesys.com> writes:
>> 
>> > The AFS code needs to store the key (at least 64 bits of it), not
>> > the inode number, or performance is doomed when interacting with
>> > reiserfs.
>> 
>> By the time that the AFS kernel code gets far enough to even obtain
>> the "key", it's already opened the file.  Unless there is a portable
>> way to obtain the key from user-space (considering that we cannot
>> presume that we're using Reiserfs).
>> 
>> Basically, what happens is that at start-time the user-space code
>> finds the inode number as I mentioned in the previous mail.  Then it
>> passes that to the kernel, and the kernel immediately opens the file
>> and pretty much keeps the file opened.  So, as long as the file inode
>> is cached between the time the user-space code stat's the file and the
>> kernel opens it, we're fine.
> 
> Not true.  Cache files are opened as needed; they are not kept open
> permanently.  Only the CacheItems file and maybe the VolumeItems file
> get that treatment.
> 

Ok, the inode cache has a limit on its size.  So, if you do something like
this:

for all cache files
    find inode number
    stat file
    put into array for kernel
end

send array to kernel

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?

The real problem here is that linux userspace needs modification to support
the new filesystems, and provide 64 bit inode numbers.  Until it does, AFS
is stuck with ext[23], or a linux specific patch.  There are a lot of ways
to do the patch, I would suggest talking with the XFS and GFS guys if you
plan to go that route.

-chris