Derrick Brashear wrote:
On Feb 19, 2008 9:28 AM, Marc Dionne <[EMAIL PROTECTED]> wrote:
There's already some code in osi_UFSOpen() and in the system call
interface to deal with filenames passed from afsd, so it doesn't look
too hard to try something like (I'll try to test this out):
- Pass file names instead of inodes from afsd to the kernel module
- Initially pass file names to InitCacheFile – this will do a lookup
and should get inodes into the inode cache if they aren't already
- Keep track of the association of file names and inodes in the kernel code
- For subsequent opening of cache files, first try iget_locked() with
the inode number. If a new inode is returned, discard it and fall
back to doing a lookup with the file name
Avoiding it entirely has the added benefit that we're effectively
cache filesystem agnostic: suddenly, you can have a cache on reiserfs.
Of course locking issues may remain. The code you see in afsd and the
syscall interface was added for MacOS 10.5, where the volfs trick
being used like iget was to be de-exported for 10.5.
I have working code (on ext3) for something similar to this that I'll
submit as part of the fixes for 2.6.25 :
- References to cache files are passed to the kernel module by inode,
directory number and V file number with a new AFSOP type.
- These numbers are stored alongside the inode numbers, and are used to
build the file name for every call to UFSOpen.
- UFSOpen has an extra parameter - it is always passed both an inode
number and a file name
- iget_locked() is first tried with the inode number - if it fails
(inode not in cache), a lookup is done with the file name
- File names for the special files (CellItems, etc.) are also stored and
passed to UFSOpen when needed
- All these changes are IFDEF'ed based on the non availability of iget()
Out of curiosity I gave this a quick try with reiserfs and xfs, and got
some oopses in both cases. So there's still other issues to work out
before these can be used.
Marc
_______________________________________________
OpenAFS-devel mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-devel
