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

[Derrick Brashear]

On Feb 19, 2008 9:28 AM, Marc Dionne <marc.c.dionne@gmail.com> wrote:
> 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 c=
ode
>  - 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.

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.