From ed740bc31e96a2dba8365f5e18f08e9cccd3cffa Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 5 Sep 2024 09:20:38 -0400 Subject: [PATCH] comment --- ..._c04b8a2a226f361bc77876875b6d17f8._comment | 27 +++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 doc/todo/use_copy__95__file__95__range_for_get_and_copy/comment_1_c04b8a2a226f361bc77876875b6d17f8._comment diff --git a/doc/todo/use_copy__95__file__95__range_for_get_and_copy/comment_1_c04b8a2a226f361bc77876875b6d17f8._comment b/doc/todo/use_copy__95__file__95__range_for_get_and_copy/comment_1_c04b8a2a226f361bc77876875b6d17f8._comment new file mode 100644 index 0000000000..6940730938 --- /dev/null +++ b/doc/todo/use_copy__95__file__95__range_for_get_and_copy/comment_1_c04b8a2a226f361bc77876875b6d17f8._comment @@ -0,0 +1,27 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 1""" + date="2024-09-05T12:56:27Z" + content=""" +The reason for reflink=always is that git-annex wants it to fail when +reflink is not supported and the copy is going to be slow. +Then it falls back to copying the file itself, which allows an interrupted +copy of a large file to be resumed, rather than restarted from the beginning +as cp would do when it's not making a reflink. + +So, at first it seemed to me that the solution will need to involve +git-annex using `copy_file_range` itself. + +But, git-annex would like to checksum the file as it's copying it (unless +annex.verify is not set), in order to avoid needing to re-read it to hash it +after the fact, which would double the disk IO in many cases. +Using `copy_file_range` by default would prevent git-annex from doing that. + +So it needs to either be probed, or be a config setting. And whichever way +git-annex determines it, it may as well use `cp reflink=auto` then +rather than using `copy_file_range` itself. + +I'd certainly rather avoid a config setting if I can. But if this is specific to +NFS on ZFS, I don't know what would be a good way to probe for that? Or is this +happening on NFS when not on ZFS as well? +"""]]