On Mon, Jun 28, 2021 at 6:35 PM Nick Couchman <nick.e.couchman@gmail.com> wrote:
On Mon, Jun 28, 2021 at 5:51 PM Frank Filz <ffilzlnx@mindspring.com> wrote:
Could you put the binary wire capture file somewhere? I find it a lot easier to read wire traces in wireshark UI…
Sure, here you go - I've done some editing to sanitize it a bit, but it should still show the overall flow:
https://drive.google.com/file/d/1PI22xjraWQ2b8HXJsySpoIkmrOe-ZIOe/view?usp=s...
-Nick
Okay, added some additional debugging information and here's what I'm seeing... * The FSINFO request over NFS triggers the nfs3_fsinfo call. * This FSINFO request triggers a call to nfs3_FhandleToCache * nfs3_FhandleToCache calls proxyv4_wire_to_host via the export->export.exp_ops.wire_to_host callback * proxyv4_wire_to_host calls HandleMap_GetFH in the handle_mapping.c file. * HandleMap_GetFH does the hashtable lookup and initially succeeds, but then fails in this section: rc = hashtable_getlatch(handle_map_hash, &buffkey, &buffval, 0, &hl); if (rc == HASHTABLE_SUCCESS) { handle_pool_entry_t *h = (handle_pool_entry_t *) buffval.addr; if (h->fh_len < fsal_handle->len) { fsal_handle->len = h->fh_len; memcpy(fsal_handle->addr, h->fh_data, h->fh_len); rc = HANDLEMAP_SUCCESS; } else { rc = HANDLEMAP_INTERNAL_ERROR; } hashtable_releaselatched(handle_map_hash, &hl); return rc; } The statement "if (h->fh_len < fsal_handle->len)" apparently is not true (so h->fh_len is either greater than or equal to fsal_handle->len), and it skips down to the next section, assigning rc the HANDLEMAP_INTERNAL_ERROR value and then bails out. -Nick