From: Joey Hess Date: Wed, 21 Sep 2022 18:32:42 +0000 (-0400) Subject: comment and todo X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~69^2~79 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=94216c99a75a199626e8c8275f2f53ab5759ca01;p=git-annex.git comment and todo --- diff --git a/doc/forum/Not_enough_free_space/comment_6_06d27155323cf5609b17c4e1197ab9ac._comment b/doc/forum/Not_enough_free_space/comment_6_06d27155323cf5609b17c4e1197ab9ac._comment new file mode 100644 index 0000000000..cda22f3bd4 --- /dev/null +++ b/doc/forum/Not_enough_free_space/comment_6_06d27155323cf5609b17c4e1197ab9ac._comment @@ -0,0 +1,41 @@ +[[!comment format=mdwn + username="joey" + subject="""comment 6""" + date="2022-09-21T17:42:44Z" + content=""" +Gus, did you manage to recover from the situation? + +I did some experimenting to see what it looks like when this happens. +Here I am in a filesystem with 76 mb free, and annex.diskreserve is set to +75 mb. The "big" file is 100 mb in size: + + joey@darkstar:~/mnt/r2>git pull + remote: Enumerating objects: 5, done. + remote: Counting objects: 100% (5/5), done. + remote: Compressing objects: 100% (3/3), done. + remote: Total 3 (delta 0), reused 0 (delta 0), pack-reused 0 + Unpacking objects: 100% (3/3), 328 bytes | 328.00 KiB/s, done. + From /home/joey/tmp/bench/r + 2dc7cd3..3699920 master -> origin/master + Updating 2dc7cd3..3699920 + Fast-forward + big | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + mode change 120000 => 100644 big + not enough free space, need 100.99 MB more (use --force to override this check or adjust annex.diskreserve) + not enough free space, need 101 MB more (use --force to override this check or adjust annex.diskreserve) + git-annex: unable to populate worktree file ./big + not enough free space, need 101.02 MB more (use --force to override this check or adjust annex.diskreserve) + git-annex: git status will show big to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git update-index -q --refresh big + not enough free space, need 101.02 MB more (use --force to override this check or adjust annex.diskreserve) + git-annex: git status will show big to be modified, since content availability has changed and git-annex was unable to update the index. This is only a cosmetic problem affecting git status; git add, git commit, etc won't be affected. To fix the git status display, you can run: git update-index -q --refresh big + +So git-annex avoids filling up the entire disk in this situation +when annex.diskreserve is configured. I suppose that you don't have +it configured, so it defaulted to only 1 mb -- and then other +things than unlocked files used up that remaining space. + +I've opened to todo that would have avoided the worst of +your experience: +[[todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default]]. +"""]] diff --git a/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn b/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn new file mode 100644 index 0000000000..f920a44826 --- /dev/null +++ b/doc/todo/prevent_pulling_unlocked_files_using_all_disk_space_by_default.mdwn @@ -0,0 +1,17 @@ +As seen in [[forum/Not_enough_free_space]], pulling +a commit that unlocks a lot of large files whose content is present in the +repository can result in an unexpected doubling of the disk space used by +git-annex. + +annex.diskreserve avoids that using up the entire disk, but it's not +uncommon for users to not have it set, and the 1 mb default can easily +be eaten up by other non-object uses of disk. + +Perhaps 1 mb is too small for the default for annex.diskreserve. Even +10 or 100 mb would leave a lot more margin for other minor uses of disk space. + +Perhaps there could be another config like annex.diskreserve but that +applies only to populating unlocked files. It could default to some larger +size, like 1 gb. Probably most users are not going to want to populate +unlocked files when their disk space gets that low. Although, the same +could be argued about just getting files. --[[Joey]]