Implement server write delegations

[chucklever]

This was bugzilla.linux-nfs.org 348

[J. Bruce Fields 2020-11-21 22:24:27 UTC] The server supports read delegations, but not write delegations. The client already has support for write delegations.

Note that we need consistency with local users of the exported filesystem; for example, we have to revoke any write delegations on a file before allowing a local user to open it for read. So, both knfsd and vfs changes will be required.

[chucklever]

[Chuck Lever 2020-11-21 22:53:15 UTC] Bruce made the comment recently that it's not clear whether the addition of write delegation support will have a significant performance impact. We should identify a few reproducible usage scenarios that demonstrate whether the additional complexity gives a suitable performance gain.

[chucklever]

[J. Bruce Fields 2020-11-22 00:14:22 UTC] I have patches that allow the server to give out fake write delegations--so the server only returns write delegations, while still implementing them identically to read delegations.

That's totally incorrect in general, but as long as your server only has a single client it will work, so it's a lazy way to start testing whether write delegations might help a single-client workload.

http://git.linux-nfs.org/?p=bfields/linux-topics.git;a=shortlog;h=refs/heads/deleg-grant-read-on-write

[chucklever]

[J. Bruce Fields 2022-01-10 21:02:28 UTC] I did do one test, by the way: just timing how long it took to untar a kernel tree with and without this patch. (The creates will take just as long, but in theory the writes and closes no longer need be serialized.) It made no noticeable difference. I didn't look into why.

More testing here might be interesting.

[chucklever]

[Chuck Lever 2022-10-16 15:08:44 UTC] Jeff suggests that a good first step would be to implement the CB_GETATTR callback.

[chucklever]

[Jeff Layton 2022-10-25 16:03:11 UTC]

The server supports read delegations, but not write delegations. The client already has support for write delegations.

Note that we need consistency with local users of the exported filesystem; for example, we have to revoke any write delegations on a file before allowing a local user to open it for read. So, both knfsd and vfs changes will be required.

Don't we already have that machinery in the vfs for leases? I'm not sure what else we'd need to implement at the vfs layer for this.

On a different note:

CB_GETATTR handles the case where there is a GETATTR from a client while another client holds a write delegation. The server can send a CB_GETATTR to the deleg-holding client and satisfy the GETATTR without having to recall it.

[chucklever]

[J. Bruce Fields 2022-10-25 18:14:31 UTC] The VFS already supports read leases, write leases, and read delegations, so you'd think we'd be most of the way to write delegations, yes.

Leases and delegations have never been exactly the same, so there's more work to do. For example, yes, I think you need to either recall or issue a CB_GETATTR on an attempt to stat a write-delegated inode.

Like read delegations (and unlike leases), write delegations would also need to revoked on metadata operations like link, unlink, rename, and attribute modifications.

I'm not sure what else might be required.