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).

Update the intro(2) manual page to better reflect the meaning as suggested by imp, cem, etal.

In D18765#401317, @imp wrote:

In D18765#401272, @mckusick wrote:

At a minimum EINTEGRITY is useful for mount since it allows the mount command to notify the user that the mount failed because of an integrity error which very likely can be fixed with a run of fsck versus an I/O error which probably cannot.

We should make mount return a different exit value for this perhaps... We could use that to automate a running of fsck in some cases.
EINTEGRITY means the end-to-end notion of what should be there isn't. This is similar to EIO (can't read the sector). The integrity error, though, means that some can't fail sanity check failed, which is a larger class of errors.

At a minimum EINTEGRITY is useful for mount since it allows the mount command to notify the user that the mount failed because of an integrity error which very likely can be fixed with a run of fsck versus an I/O error which probably cannot.

Based on feedback from Ed Maste and Ed Schouten do not add EINTEGRITY to CloudABI. Rather map it to EINVAL as is done in Linux compatibility.

It is useful to the application or user to distinguish EINTEGRITY from EIO. With EIO they know that the underlying media has failed and there is really nothing they can do. With EINTEGRITY the individual file has become corrupted, but if they still have its contents, they can remove it and rewrite it as the filesystem media itself is still working. Alternatively they can request the system administrator to run a check of the filesystem to attempt to clean up the file.