This is pretty surprising that a full disk could cause this. We write to an adjacent temporary file and only once it's fully written do we rename it into place.
But an EIO on read as shown above is also weird. What was that about? You "fixed" it? I thought we had a flag to let reindexing proceed without failing on missing files, but maybe not? On Fri, Apr 19, 2019 at 7:10 AM Anders Claesson <[email protected]> wrote: > I'll continue my monologue here with posting my solution to the file > corruption problem I experienced after my disk became full. Maybe it can be > useful for someone else in the future. As I've noted before, I'm new to > Perkeep and I'm still learning how it works, so there may very well be > better a way to do this, but here we go: > > I started by making a copy of my var/perkeep directory as a precaution. > > The file that got truncated and resulted in inconsistent hashes was a flac > fie: some-name.flac. I removed the corresponding zip/dat file under > blobs/packed/sha224/. After reading the comment in > blobs/packed/GENERATION.dat I also renamed that file to GENERATION.dat.bak > . > > This resulted in new errors, something about a missing blob/reference (I > didn't save the exact message). I (re)added the flac file: > > > pk-put file some-name.flac > > After restarting perkeepd and reindexing everything seems to work and I > see no error messages. > > Cheers, > Anders > > -- > You received this message because you are subscribed to the Google Groups > "Perkeep" 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. > -- You received this message because you are subscribed to the Google Groups "Perkeep" 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.
