From: tapesafer Date: Wed, 4 Sep 2024 14:50:16 +0000 (+0000) Subject: Added a comment: numcopies & force-trusting is ignored by fsck on readonly directory... X-Git-Tag: archive/raspbian/10.20250416-2+rpi1~1^2~21^2~39^2~3 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=2c458d7116dbc9d0830b7a5e974ab7fb4b1ba1aa;p=git-annex.git Added a comment: numcopies & force-trusting is ignored by fsck on readonly directory remotes? --- diff --git a/doc/git-annex-fsck/comment_1_80ec8617d99d3f520c22b1e7fd741c16._comment b/doc/git-annex-fsck/comment_1_80ec8617d99d3f520c22b1e7fd741c16._comment new file mode 100644 index 0000000000..ca895f210f --- /dev/null +++ b/doc/git-annex-fsck/comment_1_80ec8617d99d3f520c22b1e7fd741c16._comment @@ -0,0 +1,56 @@ +[[!comment format=mdwn + username="tapesafer" + avatar="http://cdn.libravatar.org/avatar/8a62b25ea58309a6e15cac10a5c33f1d" + subject="numcopies & force-trusting is ignored by fsck on readonly directory remotes?" + date="2024-09-04T14:50:16Z" + content=""" +I have old readonly backup media, say something like + +- `tapeA1/apples.txt` +- `tapeA2/apples.txt` +- `tapeB1/earth.svg` +- `tapeB2/earth.svg` + +I use git-annex special directory remotes to be able to navigate the directory tree that lives on those media (e.g. to decide if and which media I need to find to copy a file from that I need). +I added the remotes like so (they are too big to import with content): + +``` +git annex initremote tapeA1 type=directory directory=/tapes/tapeA1 encryption=none importtree=yes +git annex import master:tapeA1 --from tapeA1 --no-content +git annex merge --allow-unrelated-histories tapeA1/main +``` + +At some point I may buy new hardware and recreate those backup media as proper git-annex remotes, but wouldn't it be great to keep the existing backups as long as they show no sign of bitrot and together hold enough copies? + +Though, git-annex fsck behaves unexpected: It seems I cannot force trust these remotes nor does `--numcopies=0 --mincopies=0` have the desired effect. + +Concretely, when calling `git annex fsck --from=tapeA1 --numcopies=0 --mincopies=0 --trust=tapeA1 --force`, +for every file that is still intact on tapeA1, git-annex fsck reports a failure as follows + +``` +fsck tapeA1/apples.txt + Only these untrusted locations may have copies of tapeA1/apples.txt + abc-def-ghi -- [tapeA1] + Back it up to trusted locations with git-annex copy. +failed +``` + +while I'd be happy to (semi)trust tapeA1 or to accept no copies whatsoever. So fsck ignores `--trust=tapeA1 --force` and/or `--numcopies=0 --mincopies=0` which are common git-annex options that should work for fsck? + +Ideally, I would be able to (semi)trust my readonly tape remotes (which likely should be behind a `--force` as it may lead to data loss in classical directory remote settings). Then I can use git-annex to index those tapes, but also to monitor their health via fsck (so I can over the years replace the tapes that are showing signs of corruption). + +As for the corruption, I emulated bitrot on a test directory remote, which then leads to a fsck failure as follows: + +``` +fsck tapeB2/earth.svg + verification of content failed +(checksum...) + tapeB2/earth.svg: Bad file content; failed to drop fromtapeB2: dropping content from this remote is not supported because it is configured with importtree=yes +``` + +This suffices to detect tapes that should be replaced, and it's kinda expected that files cannot be dropped. + +Somehow fsck does not work as I would expect -- am I misunderstanding the numcopies/mincopies arguments here? Is there really no way to force-trust a directory remote, which to me seems appropriate in this case? Is there another way to achieve what I have in mind with git-annex? + +Thanks for this great piece of software – also use the assistant in another day-to-day usecase and it's simply great! +"""]]