diff options
3 files changed, 74 insertions, 0 deletions
diff --git a/doc/bugs/copy_unused_and_unused_not_agreeing.mdwn b/doc/bugs/copy_unused_and_unused_not_agreeing.mdwn new file mode 100644 index 000000000..68328ac96 --- /dev/null +++ b/doc/bugs/copy_unused_and_unused_not_agreeing.mdwn @@ -0,0 +1,48 @@ +[[!format sh """ +greg@x200s:~/Documents$ git-annex unused +unused . (checking for unused data...) (checking annex/direct/master...) (checking synced/annex/direct/master...) (checking synology/master...) + Some annexed data is no longer used by any files: + NUMBER KEY + 1 SHA256E-s16367--0b00ef0154c42a0bf94e5be8d92d8af27455d59794f26c33dfc39c09178521c9.pdf + 2 SHA256E-s84--b08e1c831863bb43c02158bd5e8f3f5416c3a5203d89fa94a22149460142c273.odt + 3 SHA256E-s84--ec4caae451180a29721f2b6667eec8ec80eaa724f0727cf99d2bb21bf9218e9d.odt + ... + 88 SHA256E-s84--710d69bef61674b04974ac550d713e5928563b2a12b902b64fe451705b967452.doc + 89 SHA256E-s3830--1348d6248e35625da3e22f73d2a0017185bb5e1aa37f65bbca5dfcb3c7f53034 + 90 SHA256E-s119822--7c1b53ab6402b8835473f0b5c326f3cc300ac9372be79694942c1efa4bcdc621.pdf + 91 SHA256E-s84--63b6188696795885ff6570a76a3a74799396787f7058cbcfd4a2c40b22982420.odt + (To see where data was previously used, try: git log --stat -S'KEY') + + To remove unwanted data: git-annex dropunused NUMBER + +ok +greg@x200s:~/Documents$ git-annex copy --unused --to synology +"""]] + +Is that correct behavior? I would assume the last command would at least run through the 91 files and check my synology remote that they are there. Like this repo did: + +[[!format sh """ +$ git-annex unused +unused . (checking for unused data...) (checking master...) (checking 60justin/master...) + Some annexed data is no longer used by any files: + NUMBER KEY + 1 SHA256E-s9390266--7ed16c9423b331dbe63bb3b4278b8c94a6754a07177c53fceb3b24e9610e8054.NEF + 2 SHA256E-s10435713--49cbfe8466eada2c3787c9a7e158a7dfb9845a0aa8ef862ed2578b59c889dc4d.NEF + 3 SHA256E-s9442044--85c314e318f643237df5e3adf7559e9bf268ee28f1f92d4102161865323ddeb6.NEF + 4 SHA256E-s290672--c5822c3ef16bd62b5752b2dace81182ce00d64bd4d2d994ba93e3cb94e645708.JPG + 5 SHA256E-s293288--30f1367fc326f7b053012818863151206f9e3ddeab3c3fc5b5c1c573d120d50a.JPG + 6 SHA256E-s3672986--be960f6dc247df2496f634f7d788bd4a180fe556230e2dafc23ebc8fc1f10af3.JPG + (To see where data was previously used, try: git log --stat -S'KEY') + + To remove unwanted data: git-annex dropunused NUMBER + +ok +$ git-annex copy --unused --to synology +copy SHA256E-s9390266--7ed16c9423b331dbe63bb3b4278b8c94a6754a07177c53fceb3b24e9610e8054.NEF (checking synology...) ok +copy SHA256E-s10435713--49cbfe8466eada2c3787c9a7e158a7dfb9845a0aa8ef862ed2578b59c889dc4d.NEF (checking synology...) ok +copy SHA256E-s9442044--85c314e318f643237df5e3adf7559e9bf268ee28f1f92d4102161865323ddeb6.NEF (checking synology...) ok +copy SHA256E-s290672--c5822c3ef16bd62b5752b2dace81182ce00d64bd4d2d994ba93e3cb94e645708.JPG (checking synology...) ok +copy SHA256E-s293288--30f1367fc326f7b053012818863151206f9e3ddeab3c3fc5b5c1c573d120d50a.JPG (checking synology...) ok +copy SHA256E-s3672986--be960f6dc247df2496f634f7d788bd4a180fe556230e2dafc23ebc8fc1f10af3.JPG (checking synology...) ok +$ +"""]] diff --git a/doc/bugs/copy_unused_and_unused_not_agreeing/comment_1_a11a45868867361fcff61471ffe0ce39._comment b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_1_a11a45868867361fcff61471ffe0ce39._comment new file mode 100644 index 000000000..cedc0f7f9 --- /dev/null +++ b/doc/bugs/copy_unused_and_unused_not_agreeing/comment_1_a11a45868867361fcff61471ffe0ce39._comment @@ -0,0 +1,10 @@ +[[!comment format=mdwn + username="http://grossmeier.net/" + nickname="greg" + subject="indirect vs direct" + date="2014-02-20T06:25:31Z" + content=""" +Aha! The issue is that the first repo (the one not copying unused files to synology) was in direct mode. I switched it to indirect and not only are there now a lot more files listed in unused, but copy --unused is working as expected. + +Should there be a warning in git-annex unused when in direct mode about this? I'm not exactly sure what is happening (not sure why the number of unused would go up from 91 to 296). +"""]] diff --git a/doc/todo/Use_bitcoin-mining_ASICs_for_hashing__63__.mdwn b/doc/todo/Use_bitcoin-mining_ASICs_for_hashing__63__.mdwn new file mode 100644 index 000000000..076f3ce4a --- /dev/null +++ b/doc/todo/Use_bitcoin-mining_ASICs_for_hashing__63__.mdwn @@ -0,0 +1,16 @@ +This is just an idea, and I have no idea if it would work (that's why I'm asking): + +**Would it be possible to use ASICs made for Bitcoin mining inside git-annex to offload the hashing of files?** + +I got the idea, because I have two RaspberryPis here: + +- one runs my git-annex archive. It is really slow at hashing, so I resorted to using the WORM backend +- another one runs 2 old-ish ASIC miners. They are just barely "profitable" right now, so in a few months they will be obsolete + +Both devices to some kind of `SHA256`. I have a feeling this is either extremely easy or extremely complicated to do… :) + +> git-annex uses binaries such as `sha256sum` for hashing large files (large is +> currently hardcoded as bigger than 1MB). If you insert a binary with the same +> interface as `sha256sum` into your `$PATH`, git-annex will automatically use +> it. If you want to use ASIC hashing even for small files, you need to tweak +> `Backend/Hash.hs`. --[[HelmutGrohne]] |