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 – 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 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 _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
