https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #12 from Alan Somers ---
(In reply to Rick Macklem from comment #11)
fuse_vnop_read or fuse_vnop_write might return EINTR if:
* uiomove(9) returns ERESTART or EINTR
* getblk returns NULL
* bwrite returns EINTR
* If a signal is r
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
Rick Macklem changed:
What|Removed |Added
CC||asom...@freebsd.org
--- Comment #11
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #10 from Rick Macklem ---
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #9 from Ivan Rozhuk ---
I suspect that more correct is ignore EINTR error limited times and only then
fallback to generic copy.
So IMHO usage pattern must be one of:
size_t ntry;
const size_t max_ntry = 5;
for (ntry = 0; ntr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #8 from Ivan Rozhuk ---
(In reply to Mark Johnston from comment #7)
According to man copy_file_range [1] EINTR also may happen "for files on some
NFS mounts.", so it is not new problem, it is documented behavior.
You may ask au
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #7 from Mark Johnston ---
(In reply to Ivan Rozhuk from comment #6)
Well, I'm not going to commit a patch that works around an unknown problem in
just one utility that happens to use copy_file_range().
I'm not asking you to deb
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #6 from Ivan Rozhuk ---
(In reply to Mark Johnston from comment #5)
I have no idea why this happen.
I do not try to run cp under ktrace and have no plans to debug whole kernel fs
stack.
My investigation was: "what happen with c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #5 from Mark Johnston ---
But why is copy_file_range() returning EINTR? What happens if you run cp under
ktrace (so that signals are logged as well)?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
Ivan Rozhuk changed:
What|Removed |Added
Version|13.2-STABLE |14.0-STABLE
--
You are receiving th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
Ivan Rozhuk changed:
What|Removed |Added
Attachment #242505|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #3 from Ivan Rozhuk ---
Test is OK - no error in same usecases.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
--- Comment #2 from Ivan Rozhuk ---
Created attachment 242505
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=242505&action=edit
patch
I am testing this patch.
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
Ivan Rozhuk changed:
What|Removed |Added
CC||rozhuk...@gmail.com
--- Comment #1 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
Graham Perrin changed:
What|Removed |Added
Status|New |Open
CC|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271675
Bug ID: 271675
Summary: cp: Interrupted system call
Product: Base System
Version: 13.2-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects So
15 matches
Mail list logo
