On Fri, Apr 24, 2009 at 09:47:57PM +0530, Krishna Kumar2 wrote:
> Hi Bruce,
>
> "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote on 04/24/2009 04:09:09 AM:
>
> > > Keying on the entire filehandle seems reasonable, but I don't think it
> is
> > > required as auth[3] seems to be allocated memory which is unique in a
> > > system,
> >
> > You lost me. Where do you see auth[3] getting encoded, and what do you
> > mean by saying it's "allocated memory which is unique in a system"?
> >
> > There are a lot of different filehandle encoding options. I lose track
> > of them myself....
>
> Sorry, I am wrong, I was thinking of &auth[3] and wrote too fast. I am
> testing
> using your suggestion hashing on the full filehandle, something like:
>
> {
> __u32 a = auth[0], b = auth[1], c = auth[2], d = auth[3];
> hash = jhash_3words(a, b, jhash_2words(c, d, 0), 0xfeedbeef) &
> FHPARM_HASH_MASK;
> ...
> /*
> * Matching check uses something like:
> * if (fh->p_auth1 == a && fh->p_auth2 == b && fh->p_auth3 == c &&
> fh->p_auth4 == d)
> */
> }
>
> Is what you had in mind? I am testing some more with this, so far I get
> different values for different files and filesystems.
>
> I am not sure if there is an easier way to do a hash and get the unique
> file
> associated with the filehandle, this part of the code is very complicated.
Why not just do a hash on the entire filehandle, however long it may be?
(Cc'ing Greg since he says he had some patches which did something
similar, and perhaps he could offer a suggestion.)
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
