On 04/10/2017 11:57 AM, Frank Filz wrote: >> Hi All, there is usually a 1:1 relationship (ignoring handles across > architectures >> and versions) between nfs handle and object handle. One thing that is not >> clear is the "key" which is used for hashing the objects > (mdcache_entry_t). >> Ganesha 2.5 has handle_to_key() method to take unique bits from the >> handle for acching purpose. How did this work in ganesha 2.3? Ganesha 2.3 >> comments say that extract_handle method is used to get the key, but this >> eventually results in losing the actual handle. >> >> >> Also comment at mdcache_create_handle() indicates that it takes "key" >> but the actual argument "struct gsh_buffdesc *hdl_desc" is written as >> "Buffer descriptor for the "wire" handle". Is this wire handle or key? >> If this is not the "key", then we will be looking for an incorrect object, > right? > > Looking over the code, I THINK everything is right... > > There is still a handle_digest method, and for GPFS it uses > gpfs_sizeof_handle to determine the size to copy, so that may well copy the > full handle. > > The code is definitely very confusing... > > There IS a handle_cmp method... > > I suggest we consider re-writing and clarifying all of this handle > processing code. > > I think everywhere, the handle digest should be whatever the FSAL wants > encapsulated. > > The handle_to_key function should be used to extract the key to be hashed by > anything that wants to hash things, and since we will be using that for > hashing, we should drop the handle_cmp method (or have a default version > that just calls handle_to_key on the two handles it will compare, and then > compare memory using the buffer descriptors returned by handle_to_key).
This is, in fact, what it does. > > FSALs having a custom handle_cmp isn't useful because they can't pick and > choose fields in the handle to compare (since a hash of such a discontinuous > handles would hash bytes that aren't part of the comparison, generating > different hashes for handles that are the same key). But it may be able to do this comparison faster, and avoiding copying things around. > > I THINK this really only affects GPFS which puts extra stuff into some of > it's handles that may be different at different times for the same object. > > Part of why this was never really clear is the folks who did all the stuff > really didn't understand GPFS handles (I remember lots of confusion before > we got it right). > > Frank > > Daniel ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Nfs-ganesha-devel mailing list Nfs-ganesha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
