Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 26 Sep 2020 23:33:45 +0000
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        FreeBSD Hackers <freebsd-hackers@freebsd.org>, "freebsd-current@freebsd.org" <freebsd-current@freebsd.org>
Subject:   RFC: should copy_file_range(2) remain Linux compatible or support special files?
Message-ID:  <YTBPR01MB3966966F82008C9E471708FCDD370@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM>

next in thread | raw e-mail | index | archive | help
I know cross-posting is frowned upon, but I wanted everyone who might=0A=
like to comment to see this.=0A=
=0A=
Currently copy_file_range(2) only supports regular files, which is compatib=
le=0A=
with the Linux one, where EINVAL is returned when either file descriptor=0A=
refers to a non-regular file.=0A=
=0A=
Alan Somers would like to extend the syscall to handle special files.=0A=
I think he has a couple of reasons for this (he can correct me):=0A=
- When integrating it into "cp", he needed to provide a fallback for=0A=
  special files and similar fallbacks would probably be needed for=0A=
  other utilities like "dd".=0A=
- iSCSI provides a "copy" operation which could be implemented using=0A=
  copy_file_range(2)/VOP_COPY_FILE_RANGE() if it supported special files.=
=0A=
=0A=
kib@ was concerned that a copy from /dev/zero would fill a disk, but=0A=
I think that issue can be dealt with by limiting the duration of the syscal=
l=0A=
to 1sec (so that the utility can be terminated via SIGTERM or similar).=0A=
=0A=
I am on the fence w.r.t. since I modelled it after the Linux one and keepin=
g=0A=
it Linux compatible would facilitate portable code, but I understand why=0A=
Alan Somers wants to extend it (the iSCSI support seems particularily usefu=
l).=0A=
=0A=
Everyone, please comment on this, rick=0A=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB3966966F82008C9E471708FCDD370>