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

[Derek Atkins]

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.

But yes, that is indeed what we mean.  Once the user-space sends the
list of inodes to the kernel, the user-space never touches them again.
When first passed into the kernel, the file is opened in kernel space
(based on the inode number), tested, and then closed.  This happens in
afs_InitCacheFile().  The kernel then opens and closes the files as
needed.

In order to solve the inode-cache size problem, we could change the
patch such that it does something like:

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

for all in array
    stat cachefile
    inode to kernel
end

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.

One problem is that I cannot perform filesystem-specific calls,
because I don't know a priori what filesystem I'm sitting on.
Moreover, I really don't want to require knowledge of what filesystem
I'm on in order to open a file from the kernel.  I can't perform a
resierfs ioctl, because how would that work under ext2?

Perhaps if there were an igetmagic ioctl() which would return the
'magic' number needed to later pass to iget(), I could use that.  Such
a function would return the inode number for ext2, or the magic number
of reiserfs.  Then iget() would use the magic number to return the
inode in question (based on the filesystem type).

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).

> 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.

This is certainly one problem, but not something that AFS in general
can fix.  Once the Linux userspace fixes this, then obviously AFS can
move over there as well.  However I don't care about this.  As you
said, the Linux userspace needs modification to support these new
filesystems, so I can wait until then.

> -chris

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/      PP-ASEL      N1NWH
       warlord@MIT.EDU                        PGP key available