> On Jun 15, 2017, at 7:07 AM, Olga Kornievskaia <aglo@xxxxxxxxx> wrote: > > On Thu, Jun 15, 2017 at 4:15 AM, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: >> On Wed, Jun 14, 2017 at 01:06:53PM -0400, Olga Kornievskaia wrote: >>> This is a proposal to allow 64bit count to copy and return as >>> a result of a copy_file_range. No attempt was made to share code >>> with the 32bit function because 32bit interface should probably >>> get depreciated. >>> >>> Why use 64bit? Current uses of 32bit are by clone_file_range() >>> which could use 64bit count and NFS copy_file_range also supports >>> 64bit count value. >> >> Please provide a very good use case that actually matters to a large >> portion of the Linux users. > > Reason: it will not hurt any user but it will help for > server-to-server NFS copy because for each invocation of of > copy_file_range() it requires that the client sends COPY_NOTIFY, then > COPY and then a copy triggers a establishment of clientid/session > before the reading of the source file can happen. All that could be > saved by have a 64bit value. What is the overhead of sending a couple of RPCs vs. copying 4GB of data on the server? > Current copy_file_range would work for any file size, it would just > need to be called in a loop by the application. With the given > proposal, there wouldn't be a need for the application to loop due to > the API size limitation. It might still loop if a partial copy was > done. Given that there always needs to be a loop to handle partial completion, adding the 64-bit syscall doesn't really simplify the application at all, but adds duplicate code to the kernel for little benefit. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
