On 9 May 2017 at 12:27, Mathieu Lonjaret <[email protected]> wrote: > On 9 May 2017 at 07:18, Rhythmic Fistman <[email protected]> wrote: >> >> >> Il giorno domenica 7 maggio 2017 03:38:18 UTC+10, mpl ha scritto: >>> >>> On 6 May 2017 at 03:05, Rhythmic Fistman <[email protected]> wrote: >>> > >>> > >>> > Il giorno venerdì 5 maggio 2017 23:27:55 UTC+10, mpl ha scritto: >>> >> >>> >> On 5 May 2017 at 09:00, Rhythmic Fistman <[email protected]> wrote: >>> >> > I'm in a bind with this - I ctrl-C camlistored and the kvIndexFile >>> >> > became >>> >> > corrupted (how do I cleanly stop it?) & re-indexing is taking days. >>> >> >>> >> Hmm, how come you were on kvIndexFile? I thought we had made leveldb >>> >> the default everywhere (because we indeed experienced corruption >>> >> problems with kv iirc). Did you specify kvIndexFile yourself on >>> >> purpose? >>> > >>> > >>> > Not on purpose, it's because I come back to camlistore every year or two >>> > to >>> > try and backup and deduplicate my photos, >>> > so I've got old configurations lying around. >>> > >>> > So I switched to levelDB. On my local ssd setup >>> > >>> > $ time camlistored -openbrowser=false -reindex >>> > >>> > >>> > Starting camlistored version 8f1a7df176de21d0d052c04db45b373c5c282fb1; >>> > Go >>> > go1.8 (darwin/amd64) >>> > >>> > Starting to listen on http://localhost:3179 >>> > >>> > Index wiped. >>> > >>> > Error: blobpacked storage detects non-zero packed zips, but no metadata. >>> > Please re-start in recovery mode with -recovery. >>> > >>> > >>> > >>> > $ time camlistored -openbrowser=false -recovery >>> > >>> > Starting camlistored version 8f1a7df176de21d0d052c04db45b373c5c282fb1; >>> > Go >>> > go1.8 (darwin/amd64) >>> > >>> > Starting to listen on http://localhost:3179 >>> > >>> > ui: serving Closure from embedded resources >>> > >>> > Starting recovery of blobpacked index >>> > >>> > Caught panic installer handlers: error instantiating storage for prefix >>> > "/bs/", type "blobpacked": Sum of all zips (1055150 bytes) does not >>> > match >>> > manifest's WholeSize (527575 bytes) f >>> > >>> > [...] BACKTRACE ELIDED >>> > >>> > >>> > This time reindex works in ~13 minutes >>> >>> wait, are you saying that you got a panic with serverinit, but the >>> camlistored process didn't die, and the reindexing kept going >>> successfully? >> >> >> no - -reindex failed (and exited), then -recovery failed (and exited). After >> that -reindex worked. > > oh, that's somewhat reassuring then. But if -recovery was not > successful, you might still have "invisible" blobs. I'll look into it > get back to you. > >>> > time camlistored -openbrowser=false -reindex >>> > >>> > >>> > but should I be worried that the recovery failed? >>> >>> Not worried that something is corrupted, but worried that not all your >>> blobs are reachable (because the blobpacked index is not up to date), >>> yes. >> >> >> What should I do? > > You could try restarting with -recovery again.
So yeah, we should try: 1) stop your camlistored 2) remove your blobpacked index (it should be somewhere like HomeDir/Library/Camlistore/blobs/packed/packindex.leveldb) just to be sure 3) camlistored -recovery=true if that last step goes fine, then you're good, so you can stop camlistored, and restart with camlistored -reindex=true If it does not, we should investigate further how your blobpacked server got that way, because we need to understand how it happened in order to truly to fix it. -- You received this message because you are subscribed to the Google Groups "Camlistore" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
