Timeline for Linux syscalls: advantage of copy_file_range over sendfile?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 7, 2024 at 22:15 | comment | added | gps | It is worth noting that copy_file_range() still has a lot of sharp edges on Linux. Don't use it blindly without understanding its practical implementation quirks. lwn.net/Articles/846403 | |
| Feb 29, 2024 at 0:07 | comment | added | sina bala | Yeah I think I see the advantage: if you are say a block storage layer and might have a lot of concurrent things to copy, then you either need to serialize (seek, sendfile, seek, send file...) or start dup'ing fds, just to be able to work on multiple fronts. And then the kernel would need to make sure access order guarantees (I assume sendfile had similar semantics as write when it comes to determinism when it returns), and then send out commands to the hardware. Much easier if commands are just "fire and forget" and can be issued from arbitrary many threads in parallel | |
| Feb 29, 2024 at 0:02 | vote | accept | sina bala | ||
| Feb 28, 2024 at 17:32 | comment | added | sina bala | Now that is interesting! Wouldn't have guessed it's about offloading! | |
| Feb 28, 2024 at 11:47 | history | answered | Stephen Kitt | CC BY-SA 4.0 |