On Sat, Sep 19, 2020 at 5:32 PM Konstantin Belousov <kostik...@gmail.com> wrote:
> On Sat, Sep 19, 2020 at 11:18:56PM +0000, Rick Macklem wrote: > > Alan Somers wrote: > > >On Fri, Sep 11, 2020 at 3:52 PM Rick Macklem <rmack...@uoguelph.ca > <mailto:rmack...@uoguelph.ca>> wrote: > > >Konstantin Belousov wrote: > > >>On Fri, Sep 11, 2020 at 08:49:36PM +0000, Alan Somers wrote: > > >>> Author: asomers > > >>> Date: Fri Sep 11 20:49:36 2020 > > >>> New Revision: 365643 > > >>> URL: https://svnweb.freebsd.org/changeset/base/365643 > > >>> > > >>> Log: > > >>> cp: fall back to read/write if copy_file_range fails > > >>> > > >>> Even though copy_file_range has a file-system agnostic version, it > still > > >>> fails on devfs (perhaps because the file descriptor is > non-seekable?) In > > >>> that case, fallback to old-fashioned read/write. Fixes > > >>> "cp /dev/null /tmp/null" > > >> > > >>Devices are seekable. > > >> > > >>The reason for EINVAL is that vn_copy_file_range() checks that both in > and out > > >>vnodes are VREG. For devfs, they are VCHR. > > > > > >I coded the syscall to the Linux man page, which states that EINVAL is > returned > > >if either fd does not refer to a regular file. > > >Having said that, I do not recall testing the VCHR case under Linux. > (ie. It might > > >actually work and the man page turns out to be incorrect?) > > > > > >I will test this case under Linux when I get home next week, rick > > I'll admit I haven't tested this in Linux to see if they do return > EINVAL. > > > > >Since there's no standard, I think it's fine for us to support devfs if > possible. > > 1 - I think this is a good question for a mailing list like > freebsd-current@. > > 2 - I see Linux as the de-facto standard these days and consider POSIX no > > longer relevant, but that's just mho. > > 3 - For NFSv4.2, the Copy operation will fail for non-regular files, so > if you > > do this, you will need to handle the fall-back to using the > generic code. > > (Should be doable, but you need to be aware of this case.) > > > > Having said the above, it is up to the "collective" and not me and, as > such, > > I suggest #1, to see whether others think doing a non-Linux compatible > > version makes sense for FreeBSD? > > I believe that allowing devfs nodes for vn_copy_file() is not very good > idea. For /dev/null driver returns EOF, but think about real devices or > even better, /dev/zero that never EOF its output. > > Is vn_copy_file() interruptible ? I think not. So if insane range is > specified, we have unstoppable copier that fills the disk (at best). > I can think of good use cases for copy_file_range on a device: 1) Network block devices. I don't know if the iSCSI, NBD, or Ceph RBD protocols currently support server-side copies, but it's reasonable that they might. If they ever do, FreeBSD would need copy_file_range to take advantage. 2) CUSE. I think Linux's CUSE already supports copy_file_range, since a CUSE device on Linux is basically just a single-file FUSE file system. We might add support to our CUSE driver someday. 3) zvols. This is the use case that matters the most to me. I have a large amount of data stored in plain files that I would like to convert to zvols. dd should be able to do that using copy_file_range. In my opinion, the utility of those cases outweighs the risk of a long-running interruptible syscall. And in any case, it is documented that copy_file_range may return EINTR. -Alan _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
