close as git-annex already makes reflinks when supported
This commit is contained in:
parent
3e55ddd172
commit
9313bf0eac
2 changed files with 7 additions and 2 deletions
|
@ -108,7 +108,7 @@ detail in [[todo/git_smudge_clean_interface_suboptiomal]].)
|
||||||
## using less disk space
|
## using less disk space
|
||||||
|
|
||||||
Unlocked files are handy, but they have one significant disadvantage
|
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
|
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
|
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
|
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!
|
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:
|
make the second copy not be worth keeping:
|
||||||
|
|
||||||
* When you're using git-annex to sync the current version of files across
|
* When you're using git-annex to sync the current version of files across
|
||||||
|
|
|
@ -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.
|
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]]
|
||||||
|
|
Loading…
Reference in a new issue