diff --git a/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/comment_1_a4b8273dca2e7d33c40166e34319263b._comment b/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/comment_1_a4b8273dca2e7d33c40166e34319263b._comment
new file mode 100644
index 0000000000..cc8cddae9d
--- /dev/null
+++ b/doc/bugs/Uses_rsync_instead_of___96__cp_--reflink__61__auto__96___on_volumes_of_the_same_BTRFS_partition/comment_1_a4b8273dca2e7d33c40166e34319263b._comment
@@ -0,0 +1,27 @@
+[[!comment format=mdwn
+ username="joey"
+ subject="""comment 1"""
+ date="2019-07-17T15:52:20Z"
+ content="""
+The reason git-annex uses rsync is it can resume interrupted transfers,
+and cp cannot.
+
+As well as this btrfs subvolume problem, the current behavior has the
+problem that when it uses cp on a non-CoW filesystem, it doesn't resume.
+
+It would really be nice to have a way to probe if CoW is supported for a
+given combination of src, dest.
+
+One way would be to use `cp --reflink=always` and if it fails fall back to
+rsync. But the overhead of running an extra cp command for each file, while
+at first seemingly small, is actually fairly large. 
+
+I benchmarked two shell loops over 1000 files. One did a `cp
+--reflink=always`, which always failed. That took 2 seconds. One used rsync
+to copy the (empty) file to 1000 different destination files. That took 3.7
+seconds.
+
+It seems that it would be worth the complication to try `cp --reflink=always`
+just once per remote, and if it fails, fall back to rsync for the remainder
+of the process's operations on that remote.
+"""]]