[OpenAFS-devel] Linux 2.6.25 - R.I.P. iget()

[Marc Dionne]

Hi,

I've been trying to get OpenAFS running on recent 2.6.25-rc kernels,
and have run into what looks like a serious snag: iget() has been
removed, according to the patch comment to "remove the temptation to
use iget() to find an inode by number in a filesystem from code
outside that filesystem."  Also gone is the read_inode() super-block
operation which was used by iget() to initialize new inodes.
iget_locked() is still available and exported, so existing inodes in
the inode cache are usable, but there's no direct way to call into the
former read_inode() code to correctly initialize new inodes.  For most
filesystems, this code was folded into an fs specific <fsname>_iget()
function that is not exported and not callable in an fs-neutral way
(ex: through a sb operation).

The effect when testing (with an ext3 cache) is that it works OK as
long as the inodes are in the inode cache (ex: when afsd creates new
cache files), but of course there's trouble if they're not (ex:
persistent cache after a reboot, inodes evicted from the inode cache
after a while).

I read a few threads with related discussion, mostly about reiserfs:
 http://www.openafs.org/pipermail/openafs-devel/2001-April/005809.html
 http://www.openafs.org/pipermail/openafs-devel/2000-December/005178.html

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 =96 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 cod=
e
 - 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

Presumably, cache files don't get re-opened very often and the
additional overhead should be minimal, but keeping track of a large
number of file names in the kernel module is not very appealing.

Or perhaps there's still a way to navigate the kernel API and get by
with just the inode number, but the intention seems to be to prevent
code from doing this, so there's a risk that any alternate path may be
removed later.

Thoughts?

Marc