One more patch update. This one is an optimization. If a hole is found that extends to
the end of the byte range being copied, all subsequent reads will return all 0 bytes.
This patch adds a Boolean variable called readzeros to flag this case and avoid doing
the unnecessary reads.

Oops, found one more bug during proofreading. If the hole being punched by writing 0s was
greater than blksize in length, the memset() would have gone off the end of the dat buffer.
This version has the above fixed. To make the code cleaner, I factored out the writing of a chunk
of outvp into a separate function.

During a proofread, I spotted that vn_copy_file_range() was broken if the input file had a hole
that straddled the end of the byte range being copied.
This version of the patch has that fixed, plus a typo in a comment and little bit or reordering
of the code (that doesn't affect correctness).

Change the mem_iszero() helper function to return bool instead of int, since C99 bool is now fashionable
in the FreeBSD kernel.

Changed an int to a bool, since C99 bools now appear to be fashionable in the FreeBSD kernel.

int arguments changed to C99 bool as requested by kib@.

Added replies to inline comments.

This variant allows a sleep to be done for allocation of a new list entry. It only returns NULL
if it would need to sleep waiting to be able to lock the range.

Replace vn_rangelock_rlock_nonblock() with vn_rangelock_rlock_trylock() to be consistent with D20645.

This variant of the patch has the "_nonblock" suffixes replaced by "_trylock" as suggested by asomers@.
A quick grep of src/sys/sys shows that "nonblock" is used for flags, but "_trylock" is used as a suffix
for non-blocking lock functions.

This variant of the patch rangelocks the byte ranges for both the input and output files.
It uses the vn_rangelock_rlock_nonblock() call in the D20645 patch to do this without a
risk of deadlock.

Added inline replies to the inline comments that still apply to this version.

This version of the patch avoids the problems w.r.t. concurrent locking of two vnodes
by locking/unlocking the vnodes (which also implies rangelocks and vn_start_write())
in vn_rdwr().

I am going to take the "does this sycall need to be atomic?" over to FreeBSD-fs@.
(I will copy kib@'s and asomers@ comments into the post.)

Yes, I did understand the comment w.r.t. range_locks. I fixed the rest of the stuff for two vnodes locked
concurrently, but I couldn't see an easy way to do range_locks on both of them without a LOR.

Added a question w.r.t. which way I should handle the locking of the two vnodes.

The COMPARE_ARRAYS() macro has been changed per suggestions by kib@.

The COMPARE_ARRAYS() macro has been changed to remove the "optimizations"
as suggested by kib@. It now just checks for the common case of identical
arrays by iterating through them with a for loop.
This also allowed the "typ" argument to be removed, since it is no longer needed.

W.r.t. the config file. Unless there are several who disagree with just having this always enabled,
I think it is ok to just have it always enabled and not configurable.

This version of the patch just implements the incremental update of the kernel exports
for all reloads and does not need/use the "-I" option.

Well, the main reason I made it an optional non-default option is...

• The exports file format (and the code that parses it and reloads it) is complex and I may have missed a case such that the "-I reload" doesn't get it right. --> With a non-default option, the sysadmin can just go back to the default case and that should work around the bug until it is fixed. (Since the initial load must be a full loading of the exports, the non "-I" case code needs to remain in the sources and making it non-optional wouldn't simplify the code.)

Sounds fine to me. (I'll admit I never look at man pages for this stuff and just the code, so
I didn't even notice there was a man page. Oops.)

I haven't had a Kerberos setup for quite a while.
However, Peter Errikson uses Kerberized NFS and even with a Windows KDC, I think?

Here are the results of a test run done by Peter for a hash table of the size this patch
creates and one ten times bigger:

“BigHash” (without “/ 10”)

May 18 15:06:56 filur00 mountd[66347]: time spent reading exports: 6.9s
May 18 15:06:56 filur00 mountd[66347]: time spent updating kernel: 16.4s
May 18 15:07:10 filur00 mountd[67659]: time spent reading exports: 902.5ms
May 18 15:07:10 filur00 mountd[67659]: time spent updating kernel: 17.9ms

Updated patch renames pfind_locked() to pfind_any_locked(), per mjg@'s request.

pfind_locked() has been renamed pfind_any_locked() and a comment
indicating that it finds zombies has been added, per mjg@'s request.

Replied to inline comment.