RFC: should copy_file_range(2) remain Linux compatible or support special files?

From: Rick Macklem <rmacklem_at_uoguelph.ca>
Date: Sat, 26 Sep 2020 23:33:45 +0000
I know cross-posting is frowned upon, but I wanted everyone who might
like to comment to see this.

Currently copy_file_range(2) only supports regular files, which is compatible
with the Linux one, where EINVAL is returned when either file descriptor
refers to a non-regular file.

Alan Somers would like to extend the syscall to handle special files.
I think he has a couple of reasons for this (he can correct me):
- When integrating it into "cp", he needed to provide a fallback for
  special files and similar fallbacks would probably be needed for
  other utilities like "dd".
- iSCSI provides a "copy" operation which could be implemented using
  copy_file_range(2)/VOP_COPY_FILE_RANGE() if it supported special files.

kib_at_ was concerned that a copy from /dev/zero would fill a disk, but
I think that issue can be dealt with by limiting the duration of the syscall
to 1sec (so that the utility can be terminated via SIGTERM or similar).

I am on the fence w.r.t. since I modelled it after the Linux one and keeping
it Linux compatible would facilitate portable code, but I understand why
Alan Somers wants to extend it (the iSCSI support seems particularily useful).

Everyone, please comment on this, rick

Received on Sat Sep 26 2020 - 21:33:47 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:25 UTC