mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

comment

Browse source
This commit is contained in:
Joey Hess 2016-07-19 11:06:49 -04:00
parent ba68310fe6
commit 242868eadb
Failed to extract signature
2 changed files with 24 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

2
doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__.mdwn
View file

@ -1,3 +1,5 @@
I believe cloning a repository on the same filesystem already makes use of cp --reflink=auto, but it appears that git-annex-{get,copy} use rsync even when both repositories involved in the copy/get are on the same filesystem. I believe cloning a repository on the same filesystem already makes use of cp --reflink=auto, but it appears that git-annex-{get,copy} use rsync even when both repositories involved in the copy/get are on the same filesystem.
Would it be possible for git-annex-get and git-annex-copy to use cp --reflink=auto when the source and destination repositories are on the same filesystem? Would it be possible for git-annex-get and git-annex-copy to use cp --reflink=auto when the source and destination repositories are on the same filesystem?
[[!meta title="allow remotes to do their own, smarter diskreserve checking"]]

22
doc/todo/wishlist__58___use_cp_--reflink__61__auto_for_git-annex-__123__copy__44__get__125__/comment_3_942c2decd6dda0730e2efe4ed6e6cd16._comment Normal file
View file

@ -0,0 +1,22 @@
[[!comment format=mdwn
username="joey"
subject="""comment 3"""
date="2016-07-19T14:57:14Z"
content="""
Yes, reflink is used instead of rsync when it's able to determine it's the
same filesystem.
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.
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.
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.
"""]]