Date: Sun, 20 Sep 2020 10:03:57 -0600 From: Alan Somers <asomers@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: RFC: copy_file_range(3) Message-ID: <CAOtMX2gMYdcx0CUC1Mky3ETFr1JkBbYzn17i11axSW=HRTL7OA@mail.gmail.com> In-Reply-To: <YTBPR01MB39666188FC89399B0D632FE8DD3D0@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> References: <CAOtMX2iFZZpoj%2Bap21rrju4hJoip6ZoyxEiCB8852NeH7DAN0Q@mail.gmail.com> <YTBPR01MB39666188FC89399B0D632FE8DD3D0@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Sep 20, 2020 at 9:58 AM Rick Macklem <rmacklem@uoguelph.ca> wrote: > Alan Somers wrote: > >copy_file_range(2) is nifty, but it has a few sharp edges: > >1) Certain file systems don't support it, necessitating a write/read based > >fallback > >2) It doesn't handle sparse files as well as SEEK_HOLE/SEEK_DATA > >3) It's slightly tricky to both efficiently deal with holes and also > >promptly respond to signals > > > >These problems aren't terribly hard, but it seems to me like most > >applications that use copy_file_range would share the exact same > >solutions. In particular, I'm thinking about cp(1), dd(1), and > >install(8). Those three could benefit from sharing a userland wrapper > that > >handles the above problems. > > > >Should we add such a wrapper to libc? If so, what should it be called, > and > >should it be public or just private to /usr/src ? > There has been a discussion on src-committers which I suggested should > be taken to a public mailing list. > > The basic question is... > Whether or not the copy_file_range(2) syscall should be compatible with > the Linux one. > When I did the syscall, I tried to make it Linux-compatible, arguing that > Linux is now a de-facto standard. > The Linux syscall only works on regular files, which is why Alan's patch > for > cp required a "fallback to the old way" for VCHR files like /dev/null. > > He is considering a wrapper in libc to provide FreeBSD specific semantics, > which I have no problem with, so long as the naming and man page make > it clear that it is not compatible with the Linux syscall. > (Personally, I'd prefer a wrapper in libc to making the actual syscall > non-Linux > compatible, but that is just mho.) > > Hopefully this helps clarify what Alan is asking, rick > I don't think the two questions are equivalent. I think that copy_file_range(2) ought to work on character devices. Separately, even it does, I think a userland wrapper would still be useful. It would still be able to handle sparse files more efficiently than the kernel-based vn_generic_copy_file_range. -Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2gMYdcx0CUC1Mky3ETFr1JkBbYzn17i11axSW=HRTL7OA>