Incompatibility with knfs ubuntu 5.15.0-47-generic about go-nfs HOT 5 CLOSED

To ensure that it isn't depending on the value of the cookie, I've change the code so it encrypts/decrypts the cookies with des.
The client still sends the cookie corresponding to the offset of 256 entries with a nfs.verifier eight replies prior the last one.

from go-nfs.

would you be okay with #52 to address this?

• without a caching backend specified, it will re-read / re-hash the full directory, rather than up-to-the-cookie, so it will do more work but the verifier will be stable
• with a caching backend as specified in the examples, the directory listing will be re-used - I probably need to test a bit more for corner cases around invalidation.

from go-nfs.

That looks certainly like a better approach than mine. Just two things that I would like to remark:

TLDR: I would

• not to fail on cache miss in DataForVerifier and go on and compute a new verifier, and return an NFSStatusBadCookie on mismatch, otherwise we are good to go.
• Cache the verifiers by id and verify the match by file-system path instead of the nfs handle, so that the same content doesn't cause a "false" collision on the random NFS handle for the same path

(Changes in #53)

DataForVerifier

A cache miss in DataForVerifier results in an NFSStatusBadCookie. But the cache can simply have evicted the value, or we have a collision in the ID. I would propose to simply handle it as a cache miss, and continue in getDirListingWithVerifier until you return the contents and "re-computed" verifier, and then compare the "re-computed" verifier with the one passed in, and only raise the error on a mismatch.

Caching Keys

The cache is using the verifier-id as a key, and uses the NFS-handle as a verifier to detect conflicts.
The issue here is a bit, that the NFS-handle is implemented as a random uuid, so it is different even for the same directory, But "natural" verifier-ids are the same for the same directory (such as the sha256 sum, or a timestamp).

Some way I think that could be addressed (order by effort, I think)

1. Ensuring that the verifier-ids do not collide for different NFS-handles. That means though that we have to cache the same directory content multiple times.

• Require that the implementation generates verifier-id specific for the NFS-handle (I.e. mix in the file-handle in the hash). No code change required from your side, but requires more effort from anyone implementing the interface.
• Key the LRU by verifier-id and NFS-handle.
• Create an LRU-cache per NFS-handle

2. File-system path instead NFS-handle. Requires going through FromHandle, but then the cache is shared between different file-handles for the same path.

• Validate that the verifier is the correct one the by file-system path instead NFS-handle.
• Use a pair of verifier-id and file-path as the key in the LRU. Less chance of collision, but more work.

4. Move the state into the file-handle: Try to provide a stable NFS-handle for the same file-object, but that requires detecting changes (i.e. path deleted, and new one created with same). That puts less pressure on the NFS-handle cache, but requires quite some logic.

from go-nfs.

Makes sense,

I think I'm happy with having the interface so that users can implement a more advanced cache key structure if they need one.

from go-nfs.

True, thanks for you work!

from go-nfs.