This is a follow up of (zero-copy via sendfile()) and (os.copy_file_range()). On [Linux 4.5 / glib 2.27] shutil.copyfile() will use os.copy_file_range() instead of os.sendfile(). According to my benchmarks performances are the same but when dealing with NFS copy_file_range() is supposed to attempt doing a server-side copy, meaning there will be no exchange of data between client and server, making the copy operation an order of magnitude faster. Before proceeding unit-tests for big-file support should be added first (). We didn't hit the 3.8 deadline but I actually prefer to land this in 3.9 as I want to experiment with it a bit (copy_file_range() is quite new, is still a WIP).
According to the man page of copy_file_range (https://man7.org/linux/man-pages/man2/copy_file_range.2.html), copy_file_range also should support copy-on-write: > copy_file_range() gives filesystems an opportunity to implement > "copy acceleration" techniques, such as the use of reflinks > (i.e., two or more inodes that share pointers to the same copy- > on-write disk blocks) or server-side-copy (in the case of NFS). Is this wrong? However, while researching more about FICLONE vs copy_file_range, I found e.g. this: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24399 Which suggests that there are other problems with copy_file_range?
