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

[Danilov Nikita]

Neulinger, Nathan writes:
 > >  > 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. 

reiserfs 3.5 fallback would not work. Or rather it would intolerably
inefficient (in reiserfs, inode can be looked up given two 32bit numbers:
unique objectid and objectid of parent directory (mostly). Fallback just
scans *all* possible parent objects ids and there may be billions of
them).

What I meant is some special code, that knows objectid (==inode numbers)
of afs cache dirs and uses this knowledge to speed search up. Forgive my
complete incompetence on afs.

 > 
 > 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)

NFS has similar problem, with client storing file-handle and sending it
back to the server. Neil Brown created a patch with new nfsd_operations
methods for super-block that, given dentry can prepare file-handle and
visa versa. There was earlier Lexa's patch that did the same for
inodes. But NFS file-handles are much longer than inode numbers.

 > 
 > 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

Nikita.
-- 
wotd: mindmouldered