I concur that VFS_STATFS should be done here.

With the minor changes requested, looks good to me.

What scenario would ever have v_writecount be less than zero?

Removing the function is right approach. All looks good.

My inline comment seems to have been lost. I requested that ufs_prepare_reclaim() be made static.

This change looks good to me modulo minor inline comment.

Any progress on getting this done?

This is long overdue. I would love to have these known LORs ignored.

I concur that taking evasive action is preferable to looping forever. However, we can do better than just bailing out. The kernel code checks for a bad d_reclen and if found skips up to the beginning of the next block within the directory using this code:

Looks good.

Looks good to go.

Some of the checks that I am contemplating are expensive in that they may require extra I/O operations. Another possible thing is that I may spawn a process to run a full filesystem check before proceeding with the mount. These are not things that should or need to be done in the case of a trusted filesystem. I believe that the name "untrusted" well and succinctly describes this option.

Doing asynchronous writes prevents clustering. The correct fix is to say:

Simply deleting the comments about splbio is fine. It might be helpful to change the comment to say `Called with the soft update lock held.' In many places the lock ownership is asserted which may be sufficient, or perhaps the assertion should be added where it is not already there.

Changing ufs_bamparray() to return errors rather than panicing is a helpful move forward.

Looks good to me.

Has this been resolved / committed?

Has this been resolved / committed?

This change looks correct to me.

A useful cleanup.

Should this now be closed since it was resolved in D19811?

This seems like a very useful improvement.

I would preface the actual condition "The nbp parameter is non-NULL when the mapping is for a block that contains data, one of an external data block, a direct block, or the final block in a chain of indirect blocks." before the correct clarification "If mapping an extended attribute block, nbp must point to a buffer for that block."

Looks good, thanks for clarifying -f.

Your change looks good. I'll approve once you update the suggested mandoc refinement.

I recently added the new error EINTEGRITY which is intended for use when a cylinder group or other filesystem structure has an integrity error. My initial plan is to use it for check-hash failures, but this is another good place to use it. It means that the callers of the functions that return this error need to be prepared to handle it. Specifically when allocating blocks or files trying to allocate from a different cylinder group. When deleting blocks or files, not immediately giving up, but trying to release all the remaining blocks of the file. A similar analysis would need to be used for this error (notably trying to allocate from a different cylinder group).

The addition to fstab.5 is helpful, but slightly incomplete in that it is not clear in what context the update keyword would be used.I would add text at the end of your new block that says something like:
The
.Dq update
option is typically used in conjuction with two
.Nm
files.
The first
.Nm
file is used to set up the initial set of file systems.
The second
.Nm
file is then run to update the initial set of file systems and
to add additional file systems.

Note that update of manual page date fell out on corrective update.

Looks good.

As noted, date at top of manual pages needs to be updated (which I will admit, I failed to do when I added underscores).