allow remotes to do their own, smarter diskreserve checkinggit-annexhttp://git-annex.branchable.com/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/git-annexikiwiki2016-07-19T15:12:47Zcomment 1http://git-annex.branchable.com/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_1_bbbb9c4c71b8c56eaf134b794d2345c3/jscinoz2016-07-18T06:17:57Z2016-07-18T06:17:57Z
Oh, my mistake. It appears git-annex already does this - I mistakenly had one of the repositories in a different btrfs subvolume.
comment 2http://git-annex.branchable.com/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_2_1eb09a234616cb0df7fed9016827dd0c/jscinoz2016-07-18T06:32:53Z2016-07-18T06:32:53Z
I suppose one enhancement could be to ignore annex.diskreserve when content is obtained by reflink copy, but I can imagine this would be difficult to achieve, since we don't know in advance whether or not --reflink=auto will actually result in a reflink copy. I imagine you could try reflink=always first, ignoring annex.diskreserve, then if it fails, fallback to reflink=auto where annex.diskreserve is checked, but perhaps this is too much filesystem-specific logic to be appropriate in git-annex.
comment 3http://git-annex.branchable.com/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_3_942c2decd6dda0730e2efe4ed6e6cd16/joey2016-07-19T15:12:47Z2016-07-19T14:57:14Z
<p>Yes, reflink is used instead of rsync when it's able to determine it's the
same filesystem.</p>
<p>Not checking diskreserve for reflink (and also for hard link when
annex.hardlink is set) would be nice. But, it's a layering problem
since currently the diskreserve check is done separately from the transfer.</p>
<p>The same layering problem also makes downloads from encrypted special
remotes not check if there's space for both the encrypted and de-encrypted
file content, in cases where both files are present on disk at the same
time.</p>
<p>So, there would be multiple benefits to improving the api somehow so more
smart diskreserve checks can be done. Although I'd then worry that if
remotes were responsible for doing diskreserve checks, they might be buggy
and forget to check.</p>