[reiserfs-list] RE: [OpenAFS-devel] weird issue with reiserfs on 2.4.3 and openaf s

[Neulinger, Nathan]

>  > Until then, I'd like to find a way to make reiserfs+AFS 
> play nice.  This
>  > either means keeping the inodes pinned (ick), or finding a 
> way to have AFS
>  > sends us the extra 32 bits.  I'm more than willing to help 
> out with that,
>  > we just need somewhere in AFS to store the 32 bits.
> 
> If AFS stores files in a few cache directories in can try their
> object-ids in sequence. This will be slow, but much faster than brute
> force search.

Right! That's why I was asking about putting the fallback back in. It can't
hurt anyone if it isn't used, and in this case, it's not a terribly
inefficient operation, since the ideal AFS cache is dedicated to the task. 

Right now, I either have to:

	A. go back to using ext2 for /afscache (what I've done)
	or
	B. use an ugly hack to make it work (keep files open in kernel)
	or
	C. Not use 2.4.3 until afs is modified to take reiserfs into account
in kernel

To me, a file system, or any other system, should never fail if it is
"possible" to do what is being asked. If is isn't efficient, so what, that's
the fault of the person asking it to do something non-ideal, but at least it
should work.

Here's what I'd like to see:
	A. Apply the "stat the file before iget" patch to afsd. That takes
care of the user space concern, and optimizes the cache-scan case.
	B. Put the fallback back into reiserfs so at least the worst case
scenario doesn't cause kernel panic.
	C. I'll be happy to work with Chris to make changes to linux afs
kernel module to do reiserfs specific code if reiserfs detected.

----

Thoughts on iget:

	Perhaps a simple way to do the interface for this would be:

	struct inode *iget_hinted(struct sb, int inum, void *hint)
	void *inode_hint(struct inode *inode);
	void *inode_freehint(void *hint)

That would be generalized enough that a hint could be retrieved from an
inode that has been fetched, and then could be passed to iget_hint() on any
future usage.

-- Nathan