How useful should copy_file_range() be?

Posted Feb 18, 2021 15:44 UTC (Thu) by dullfire (guest, #111432)
Parent article: How useful should copy_file_range() be?

I'm not sure adding the ability to report if the sort copy was due to the read or the write is really worth while.

However if that was really desired: I imagine a fairly simple way to do that is: add a flag, something like CFR_UPDATE_OFF_SIZE. Setting it would make the kernel update the loff_t's (pointed to by off_in and off_out) with the bytes read/written correspondingly. Userspace can easily tell which side failed then. If the two sides are equal, it was a read size failure, if the read side is greater, it was a write failure. Note that it is a logic error is the write size were to be greater than the read size.

How useful should copy_file_range() be?

Posted Feb 18, 2021 15:48 UTC (Thu) by dullfire (guest, #111432) [Link] (1 responses)

Never mind, failed to re-read the man page before commenting. Seems the kernel already does this.

So either the author was mistaken and it's not actually an issue, or the kernel doesn't update the read-size loff_t when there is a write failure, in which case the flag would just change this behavior

How useful should copy_file_range() be?

Posted Feb 18, 2021 16:43 UTC (Thu) by matthias (subscriber, #94967) [Link]

As I understand the man page, the offsets are adjusted by the number of bytes copied. So if you read n bytes and only write m<n bytes, then both offsets are adjusted by m.