Date: Thu, 11 Apr 2024 00:06:25 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 271675] cp: Interrupted system call Message-ID: <bug-271675-227-tmeJt5m9yP@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-271675-227@https.bugs.freebsd.org/bugzilla/> References: <bug-271675-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D271675 --- Comment #10 from Rick Macklem <rmacklem@FreeBSD.org> --- I believe the EINTR would be coming from the I/O operation done by sshfs. For the NFS mounts, it occurs for "soft" mounts when the NFS server takes too long to reply to an RPC. - It was returned by the copy_file_range(2) syscall since the same happens for a read(2) or write(2) done on such a mount. Although "soft" is not a great mount option, getting EINTR from an NFS mount would normally indicate "hung NFS mount" and termination of "cp" seems appropriate when that happens. I think the EINTR is most likely being returned by vn_rdwr(), which would be doing VOP_READ()/VOP_WRITE(). I'd guess that sshfs is an out-of-src port and that, for some reason, the VOP_READ()/VOP_WRITE() is returning EINTR sometimes? I suppose that vn_generic_copy_file_range() could ignore EINTR (and return 0) when some data has been copied (since it is allowed to return less than requested and that does not indicate "near EOF"). As Mark said, it would be nice to know why sshfs is returning EINTR and when. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-271675-227-tmeJt5m9yP>