The sys/kern/vfs_syscalls.c and sys/sys/fcntl.h changes LGTM with one small note

Do we have to do something w/ namecache?

In D57658#1323019, @emaste wrote:

Do we have to do something w/ namecache?

It is up to fs. Yes, there is a missing part for tmpfs when namecache is enabled.

I've applied the patch to my tree and will give it a try in Halifax next week.
For reference, OpenZFS commit that added Linux support: https://github.com/openzfs/zfs/commit/dbf6108b4df92341eea40d0b41792ac16eabc514

Thanks to Air Canada giving me an unexpected few hours in YYZ I had a chance to try this out. One remaining issue w/ the tmpfs support - missing directory timestamp update.

I now have a kernel panic from an attempt to swap with source missing, e.g.

#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
 
int main(void) {
    close(open("target", O_CREAT | O_WRONLY, 0644));
    renameat2(AT_FDCWD, "does_not_exist", AT_FDCWD, "target", RENAME_EXCHANGE);
}

Does filemon_wrapper_rename() need an update? I guess it should emit two records, one for each direction of the rename, but I'm not sure. cc @sjg @stevek

Are there any command-line utilities in the base system which could make use of this?

In D57658#1325504, @markj wrote:

Does filemon_wrapper_rename() need an update? I guess it should emit two records, one for each direction of the rename, but I'm not sure. cc @sjg @stevek

This thing does not even wrap renameat(2), neither it wraps renameat2(2).

In D57658#1325515, @markj wrote:

Are there any command-line utilities in the base system which could make use of this?

Might be, but I do not have an example that I can thought of.

In D57658#1325551, @kib wrote:

Set WILLBEDIR for fromnd of tvp is VDIR.

As a note, I think that WILLBEDIR is not too critical there. It basically allows to have slash after the file name to not choke the namei() parser. VWRITE vs. VWRITE | VACCESS seems to be irrelevant at all because we overwrite the same dirent.

This cannot be implemented in UFS since a requirement of its consistency model is that the on-disk image is always consistent. If the directory entries being swapped are in two different disk blocks, then there is no order of writing that will have a consistent filesystem. The only way to ensure consistency is to have a journal that can correct the unwritten directory name with its updated inode number.

In D57658#1331127, @mckusick wrote:

This cannot be implemented in UFS since a requirement of its consistency model is that the on-disk image is always consistent. If the directory entries being swapped are in two different disk blocks, then there is no order of writing that will have a consistent filesystem. The only way to ensure consistency is to have a journal that can correct the unwritten directory name with its updated inode number.

In other words, it cannot be implemented for SU, but can for async and for SU+J, do you agree?

In D57658#1331128, @kib wrote:

In D57658#1331127, @mckusick wrote:

This cannot be implemented in UFS since a requirement of its consistency model is that the on-disk image is always consistent. If the directory entries being swapped are in two different disk blocks, then there is no order of writing that will have a consistent filesystem. The only way to ensure consistency is to have a journal that can correct the unwritten directory name with its updated inode number.

In other words, it cannot be implemented for SU, but can for async and for SU+J, do you agree?

SUJ only journals things that SU is tracking. It is not a general journalling mechanism. So, if SU cannot do it, then SUJ cannot do it either. Since async makes no promises about consistency, it could implement anything it wants. But I would be loath to say that you have to run async in order to get a certain feature as I would not want to encourage use of async. My attitude is that UFS reliability has been a hallmark of its existence and I do not want to introduce a feature that removes its reliability. Especially a feature which is of such little use.