This looks like the correct solution to me. We are at the point where we decide we need to do a forcible unmount and realize that we are about to do it on the root filesystem.

For system calls you do need annotations, you cannot properly understand the purpose of any pointer passed to syscall otherwise. Is it in, out, in/out, or even just an abstract address like mmap/munmap/madvise arguments?

For ioctls, the meaning of the command/arg is quite formalized, at least in BSDs. You are well aware that we encode both sizes and directions for copyin and copyout. After I took some time thinking how to implement what you described, I was surprised by the statement that syscalls are easier than ioctls.

That said, I am quite dislike extending the syscall semantical coverage by adding one-off operations. In the case of special fds, having all ops grouped together (under ioctl umbrella) localizes the interfaces and make them more comprehensive. This is, of course, my opinion, but all my experience supports the claim.

Now looks good. Sorry for the slow response.

The use of brelse in makefs/ffs/ffs_balloc.c is inconsistent. Assuming you are consistent in having bwrite brelse in both error and non-error cases there are two places in ffs_balloc.c that need to have brelse removed.

Looks ready to commit.

Have you verified that these changes resolve the issues reported in PR #270587?

Looks good.

This looks ready to go to me. I concur with putting off your other issues for another change later.

In D39246#894573, @chs wrote:

The concern I have with this change is about user interface. With this patch, if someone renames a directory that is the root of a subtree containing other directories and then unmounts the file system cleanly, fsck will report that the file system is now corrupted because all of the dirdepth values for directories in that subtree are wrong. In fact, every existing file system will immediately be reported as corrupted the first time that the new fsck is run. There are millions of people in the world who know what the fsck output for a clean and uncorrupted UFS file system looks like, and that clean fsck output is very easy to recognize because it's very short and always the same (modulo the line with the last-mounted-on path and the line at the end with the block/inode usage and fragmentation summary). After this patch, fsck can produce millions of lines of output for file systems that aren't really corrupted but rather are merely not optimal, and it will no longer be so simple to tell if a file system is corrupted or not by looking at the fsck output.

I think that fsck should not report incorrect dirdepth values at all, because an incorrect dirdepth value is not considered corruption. It would still be desirable for fsck to set the dirdepth fields to their optimal values, but producing potentially a huge number of lines of output while doing so would obscure the fact that the file system may otherwise be completely consistent, so it would be best if these updates to dirdepth values were done silently. I realize that this changes a different long-standing tradition that fsck reports (and asks about) every individual change that it makes, but prior to this patch, everything that fsck would change represented either a kernel bug or a hardware failure of some kind (ie. a serious problem), whereas a dirdepth value being wrong is a normal situation that the kernel creates intentionally and is thus nothing to worry about.

Responding to comment.

These changes look good. I recommend adding the changes to the df(1) and msdos(5) man pages here so it all gets checked in together.

IMO not adding extra deductible data to the on-disk format is good, or if we do add such data, then we should check it dynamically. I think you would go with the dinode field re-use, but then please check that the condition that I formulated, and do the usual action when the broken metadata detected.

I do not mean to check it all way back to the root. I mean, if ufs_lookup(dvp) found vp which is directory, then vp.dirdepth must be dvp.dirdepth + 1 or both must be zero.

In D39246#893800, @kib wrote:

If I mount a filesystem without running fsck on it at all, then the things are undefined? For instance, I often boot my crash boxes single-user and directly mount some partition r/w

Thanks for cleanup.

Looks ready to go. Happy the change ended up so simple. I have the equivalent changes ready for UFS/FFS:

In UFS/FFS we handle the mangled '..' entry by silently ignoring the error and proceeding with the removal of the old directory entry. That leaves the only cleanup for fsck is to fix the broken '..' entry. I think that is what you should do too.

Since I'll be traveling for one week without good Internet access, I'll probably not be able upload the updated patch before 2023-03-20, though.

No rush. I hope some of your travel will be for fun.

Improvements so far look good.
Several places already noted still need new or updated comments.
Should add updates to msdos(5) and df(1) manual pages.

In email to me Stefan Esser writes:

I'm not happy with the choice of function names for the increment/decrement macros, and I think that the exact location of their invocation should be reviewed with regard to error cases.

In D38987#887669, @se wrote:

In D38987#887609, @mckusick wrote:

This looks like a useful change. How difficult would it be to make it also work for FAT32 filesystems?

FAT12/16 have a fixed number of directory blocks between the FAT tables and the data area.
FAT32 does away with a fixed root directory and uses kind of a 1st level sub-directory for root directory entries instead (i.e. there is a single block pointer in the boot block which points at the start of a directory "file" of variable length).

Since there is no size limit for the root directory on FAT32, there is no limit on the number of "inodes" as reported by statfs().
Both the number of inodes and of free inodes are reported as 0 and the df command deals with this special case by not reporting a percentage of free inodes.