Further testing by other people confirmed my worry this is too trivial to fix the problem without running into other side effects, thus I'm dropping the thing.

i386 kernel is being retired

First and foremost my apologies this fell through the cracks.

In D43488#991564, @pjd wrote:

In D43488#991394, @mjg wrote:

What's the motivation here? If you are running into scalability problems, it has to be allproc and proctree locks (amongst others).

Yes, scalability is the main motivation. We have a machine that slows down considerably when we reach >10,000 process (64 core system). allproc and proctree are the main problems. This change is just a low hanging fruit where we can easily eliminate a global lock.

this macro should be eliminated, not exposed

What's the motivation here? If you are running into scalability problems, it has to be allproc and proctree locks (amongst others).

Linux folk explicitly designed openat2 to be extensible, so I expect it is going to pick up explicit "official" usage down the road.

sounds like the thing to do is to add openat2 so that this automagically works, instead of a freebsd-specific flag

why is this port still a thing

@markj ping?

First of all my apologies, this somehow fell through the cracks after i pinged.

• correct diff

So again what's the benefit of bubbling up ENOSYS? I assumed it would at least get handled in a post-vop hook instead of going all the way up to the caller.

if it does work with the patch, you should paste how dmesg looks like with it

according to your own copy from dmesg this failed to attach, so it does not work?

The patch looks correct, but commit message needs some work.

I massaged what I mean into a patch, with your nullfs change as basis:

In D42603#972555, @kib wrote:

I plan to do something different after this patch goes in.
Most complications for fs come from the need to call vn_generic_copy_file_range() as fallback. I intend to make a special return code (or just repurpose ENOSYS) to ask VFS to do that after VOP call. It seems that this even eliminates the need of the flag to allow cross-mount copies, not sure completely. That would fit the idea that VOPs should implement just fs-specific code.

The VFS layer trying to babysit all filesystems is a long standing design flaw, which adds overhead to everyone and only makes optimisations clunky. For example for almost all filesystems VOP_CLOSE has next to nothing to do and most definitely does not need write suspension nor the vnode lock (and for zfs the routine is a nop) -- if there was no attempt to decide for the filesystem what it needs, there would be no problem.

vn_copy_file_range passes down vnodes from different mount points and all filesystems implementing the vop (apart from zfs) have an explicit check that mount points patch. iow the check that this is an instance of the same filesystem type is redundant for their case.

If you can rebase both changes and show me how to collect fragmentation stats I can test this against a full ports tree build.

I don't know if the kernel is in shape where this can be properly evaluated.

The code works but has a nasty corner case -- what if the process has only 2 fds opened, say 0 and 8364742 (or some other high number). Then you copy out out rather huge bitmap and force it to scan it.

I think this is a pretty weird choice.