Hans Petter Selasky wrote: >On 2019-07-05 02:28, Rick Macklem wrote: >> I am thinking that copy_file_range(2) should do this also. >> However, if it returns an error, it is impossible for the caller to know how >> much >> of the data range got copied. > >How can you kill a program stuck on copy_file_range(2) w/o catching signals? Well, if "stuck" means sleeping somewhere inside the VOP_WRITE() call for the file system, I think it is "stuck" forever, just like write(2), isn't it?
For NFS, the "intr" option might allow write(2) to return EINTR, but it often takes a forced dismount (actually "umount -N") to get it "unstuck". However, I think for the case where the signal is detected outside of VOP_READ()/VOP_WRITE() in the copy loop, it does make sense to terminate it and I think the suggestion of returning "bytes copied" instead of EINTR is a good one. rick _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
