Re: cache fixes (redux) (a tale of many inode numbers...)

[Eric Van Hensbergen <ericvh@kernel.org>]

Okay, been delving through this code.  Most (all?) was added by
Aneesh when he did the cache stuff and I clearly wasn't paying
close attention a decade ago (mostly because I didn't care about
the cache then).  In any case, I think there is a ton of code
I am going to be able to delete (patches coming soon), but wanted
to sanity check one thing with you folks.

Looking at the inode get code (which also doubles as inode creation
code).  The inodes are hashed with qid2ino(qid) which I get to take
the blame for because its been there for 18th years.
If the size of the inode_tt is 64-bit, it just
assigns the qid->path+2 (+2?) to the i_ino.  If not (presumably for 32
bit) it sets the inode to (qid->path+2) ^ (qid->path+2 >> 32). 

If ino_t goes to 64 bit this means we reduce precision for no reason,
so that has to be fixed -- but I'm trying to remember the relevance
of +2 which dates back all the way to the original submission.  I
don't remember why we did this, but I think I'm gonna kill that in
one patch and in a second patch fix the length check.

Moving up the stack a bit, we use the modified qid.path to hash the
inode, but then we also assign it (overriding the allocated inode number
on the client).  I'm gonna say this is wrong (definitely wrong in the
case where we are allocated inodes willy-nilly) and we should probably
continue to use qid.path to hash, but then keep the client side inode
number which is guarenteed unique on allocation.  Or do you folks think
we should align client-side inode with server-side inode to help with
debug?  We should still have consistent qid->paths regardless.  Thoughts?

        -eric