close as git-annex already makes reflinks when supported

This commit is contained in:
Joey Hess 2022-11-14 13:29:27 -04:00
parent 3e55ddd172
commit 9313bf0eac
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
2 changed files with 7 additions and 2 deletions

View file

@ -108,7 +108,7 @@ detail in [[todo/git_smudge_clean_interface_suboptiomal]].)
## using less disk space
Unlocked files are handy, but they have one significant disadvantage
compared with locked files: They use more disk space.
compared with locked files: On most filesystems, they use more disk space.
While only one copy of a locked file has to be stored, often
two copies of an unlocked file are stored on disk. One copy is in
@ -119,7 +119,10 @@ The reason for that second copy is to preserve the old version of the file,
when you modify the unlocked file in the work tree. Being able to access
old versions of files is an important part of git after all!
That's a good safe default. But there are ways to use git-annex that
(Some filesystems including btrfs and xfs support reflinks, and on those,
the extra copy is a reflink, and takes up no additional space.)
So two copies is a good safe default. But there are ways to use git-annex that
make the second copy not be worth keeping:
* When you're using git-annex to sync the current version of files across

View file

@ -1 +1,3 @@
Some filesystems, like BTRFS or ZFS have copy on write support, which means that if files are copied in a special way they share sectors until one of the files is edited. Implementing support would make files take up less space if they are in unlocked mode and not significantly edited.
> Already [[done]]. I did add a mention of it to the tip. --[[Joey]]