As has come up many times in the past, we have a long-standing problem, or family of problems, where in the course of operating on a particular file system we end up not calling the file system's own vnode or fs operations, but the root file system's operations. This causes varying degrees of lossage depending on exactly what happens.
One of the ways this happens came up today while working on PR 47937. The vnode structure has both a v_mount field and a v_specmountpoint field(*); both are pointers to a struct mount (that is, a filesystem) and it's very easy for people to use the wrong one, or not be sure which is which. (*) v_specmountpoint is not actually a field, it's a fake field provided by a macro. In the short term, to reduce the confusion I would like to make the following changes: 1. Rename v_mount, which is the filesystem the vnode is on (almost always / for device vnodes), to "v_myfs". 2. Rather than renaming v_specmountpoint, which is the filesystem mounted on a device vnode, kill it off entirely, and replace it with an inline (or noninline) function "specvn_getmountedfs()". Make this function assert if called on a non-VBLK vnode instead of silently producing trash. This is going to be a fairly large massedit, but I think it's worthwhile for clarity even if it doesn't turn up any mistakes. And I expect it to turn up at least a couple howlers. :-/ Also, while doing the edit, where feasible stop retrieving the fs structure from the vnode structure (or other structures) by going through the device-mounted-on. There should in general be no reason to do this at all; a filesystem's own structures should all have adequate pointers to one another without going through the device. In the long run, I think we should rearrange the way device vnodes are handled, so that the device vnodes seen and handled belong entirely to specfs and the vnodes for the on-disk inodes are stubs hidden behind the specfs vnodes. This would make it much more obvious when the wrong fs's ops get called; also it would have the generally beneficial effect of allowing a lot of rote cut and paste filesystem stuff for supporting device nodes to be flushed. More on that when my ideas solidify a bit. -- David A. Holland dholl...@netbsd.org