I know, but there's a bug somewhere here. As mentioned, the fix wasn't a priority for us, as I consider the idea itself flawed and carries a high risk of data loss.Therefore, we haven't investigated further.
We'll likely implement a switch in zfsd to prevent this behavior. We'll then provide a patch

Let me try to translate:
Sun/Solaris made defaults for the ZFS properties targeting the enterprise market.
In the linux environment some of these defaults were changed for the needs of desktop users and hobbyists.
FreeBSD now use the changed defaults.
Find the error.

We don't need support from Klara. My team is doing a great job.
I'm generally concerned with the quality standards that have characterized FreeBSD for decades.
My mistake was sharing my thoughts about FreeBSD's direction here.
The lower the claim, the easier it is to sell support, I understand.

I have the impression that it measures how long an inactive path hasn't been used, which is obviously incorrect.

However, it appears to be a measurement error/bug that (in our case) only occurs in conjunction with NetApp E-Series 57xx filers and GEOM Multipath. Other SANs don't seem to be affected.

Since I consider a deliberate reduction in redundancy due to I/O fluctuations in a wide-area fabric to be absurd, I haven't conducted any further investigations.

There are more things missing with Linux: Look at jailed and zoned zfs properties for example.

Or to put it bluntly:
The move to OpenZFS has actually only brought disadvantages for me and my business.
I used to be able to be absolutely certain that the data was secure.
Today (see the zfsd topic!) I have to pay close attention to the commits because data security no longer plays a role. Sad!

Years ago I was able to use FreeBSD just as it is for real stuff.
Now the list of things I have to change, even to recompile is getting longer and longer.
This tells me that FreeBSD is going in the wrong direction.
As someone who has lived in the BSD community for 40 years, this is a very sad fact.

Changing atime and relatime zfs properties to the "linux" defaults breaks the POSIX requirements for filesystem time attributes.
Why? Because some script kiddies want better performance?
Because we tune FreeBSD for benchmarks?
Okay, but we're losing sight of what FreeBSD should actually be!

In a high-security environment where real important things, not just money, are at stake, FreeBSD is used because it is not Linux.
So why is Linux a benchmark for us?
From github.com/freebsd/free...:
"Let's be consistent with other file systems on Linux."
Fuck, NO !!!

Why are changes which can harm the data be commited in FreeBSD? We are NOT the Linux folks, we do real business!
And then look at the changes of some ZFS DEFAULTS:
compression, atime, relatime...

We're using FreeBSD in an enterprise environment here.
We had major issues with recent changes.
cgit.freebsd.org/src/commit/?... for example broke pools because nobody thought that there are enterprise scenarios where you use fibre fabrics and it's pointless to drop a perfect working redundancy.