Please describe the problem.
Running adjust --unlock is unexpectedly slow and seems to use a lot of space, even on BTRFS, suggesting it probably does not use --reflink=auto like most other commands.
What steps will reproduce the problem?
Run adjust --unlock with very large files.
What version of git-annex are you using? On what operating system?
6.20170101-1+deb9u1 on Debian Stretch
Have you had any luck using git-annex before? (Sometimes we get tired of reading bug reports all day and a lil' positive end note does wonders)
Yes I have! I've used it manage lots of video editing disks before, and am now migrating several slightly different copies of 15TB sized documentary footage from random USB3 disks and LTO tapes to a RAID server with BTRFS.
Yay, this got fixed some time ago, by making the smudge filter not output the file content at all, but instead the link, and having a git hook later run git-annex to populate the files, which it does use reflink for when possible. done --Joey
What happens is
git annex adjustcreates a branch and runsgit checkoutto check it out. Then git callsgit-annex smudgeon files, and unfortunately the git smudge interface requires that git-annex output the whole content of the file, to stdout, which git then writes to disk.So yes, this doesn't use reflinks, but it's worse than that, a better interface would let git-annex simply move or hard-link the file into place, even on filesystems not supporting reflinks.
This is discussed in detail in ?smudge. Unfortunately it will need a better interface in git to be addressed, and that's why v6 is still an experimental feature.