add the Deallocate operation to the NFSv4.2 server

[rmacklem]

Summary

The recently added VOP_DEALLOCATE(9) VOP call allows
implementation of the Deallocate NFSv4.2 operation.

Since the Deallocate operation is a single succeed/fail
operation, the call to VOP_DEALLOCATE(9) loops up to
20 times to complete the operation.
Is 20 iterations enough?

Where RFC 7862 underspecifies behaviour, the code
is written to be Linux NFSv4.2 server compatible.

Test Plan

Tested with both the Linux and a patched FreeBSD client.
(Patch not yet here or in main.)

The key code area for review is in nfs_nfsdport.c
line #s 6613-6621, which is where the VOP_DEALLOCATE(9)
call is done.

[khng]

sys/fs/nfsserver/nfs_nfsdport.c

6618

A try count of 20 times may not be sufficient on a slow media given a huge request. I suggest either KASSERT progress are made (i.e. returned len != the len passed to VOP_DEALLOCATE), or use VOP_PATHCONF to check if a native implementation of VOP_DEALLOCATE is available or not, and return unsupported if such implementation is not available.

[rmacklem]

Change the loop doing VOP_DEALLOCATE() from a
limit of 20 iterations to checking that len is decreasing on
every iteration.

NFSERR_NOTSUPP for an NFSv4.2 operation is per file
server and not per file, so it cannot return notsupp based
on the underlying file system (might be a mi within a server).

I have posted on [e-mail] w.r.t. how best to handle
large requests that might take a long time to complete.

[khng]

The VOP_DEALLOCATE bits look good to me.

[khng]

One thing to note, it might be good to periodically do maybe_yield when looping the call so that it won't early return when should_yield() in the default implementation is hit. This avoids everytime the call performs one chunk of the IO and returns.

[rmacklem]

Add a call to maybe_yield() inside the loop that
performs VOP_DEALLOCATE(), as suggested by khng@.