ZFS 2.1.2 : sendfile(2) failing with EAGAIN on a 4.14 kernel?

[RJVB]

I'm (still) running ZFS 2.1.2 (as root) on an older system that I usually boot under kernel 4.14.23 .

I'm seeing more and more error 11 (EAGAIN, resource temporarily unavailable) when applications try to move downloaded files from a temp. to their target destination and I wonder if this is in fact the same issue discussed in #12971 that was (apparently) fixed in a later 2.1.x release (which one?).

This is clearly related to the target being on a ZFS pool or even to the source being on a pool. This seems to vary; I've had the rustup installer (downloaded by the interface script as /tmp/rustup-init, which moves itself to the target location) fail with "OS error 11" if the target is on a pool but not if it's on another FS. I checked, and rust indeed seems to use sendfile for this kind of operation, so I wrote a cli interface around sendfile(2). This fails with EAGAIN regardless of the destination when the source is on a pool.

I build and install ZFS through dpkg and a PPA, which has become trickier than it used to be and given the risk of locking myself out of my system I try not to update without good reason.

[rincebrain]

2.1.3 fixed it.

[RJVB]

Great, thanks! That upgrade shouldn't be too risky I guess. Now ... I wrote an overloaded sendfile(2) function that has a fallback in case of EAGAIN, which helps working around the issue in a little test utility but not in applications like the rustup installer or Chrome/ium (which fails to move downloaded extensions into place with an EAGAIN error). Are there other syscalls that fail like sendfile()?

[rincebrain]

The specific commit that affects this is 70b7b19, I believe, if you want to go spelunking on what can and can't break with it. I have long since forgotten if I ever saw anything but sendfile do it.

[RJVB]

That's be a sort of reverse spelunking, because it's nearly impossible to find out what calls those applications make that fail... In Chromium's case the version of the failing function (base::Move()) in the current HEAD uses rename(2) ... which cannot raise EAGAIN according to my documentation, so go figure...

[rincebrain]

I suspect that the problem is that a function is not supposed to be letting EAGAIN squeak out but the internal interface changed to allow it because you're supposed to use a different way of handling it now, but when this check doesn't include using the new function, it doesn't handle that, because the old case doesn't have it happen before that function became available.

But that's just a guess.

Don't forget that rename can turn into cp-then-rm cross-mount, though, with all the errors that implies.

[RJVB]

Or, there is a similar issue with the `copy_file_range` syscall. It seems that's what the failing rust file copy implementation uses on Linux.