New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Db corruption observed with powerloss #333

Open
apurvcohesity opened this Issue Jan 20, 2016 · 1 comment

Comments

Projects
None yet
2 participants
@apurvcohesity

apurvcohesity commented Jan 20, 2016

I have the following db that we can open for reads but every attempt to write fails with:
Corruption: not an sstable (bad magic number)

I am not sure which ldb file is corrupt (there does appear to be 1 0 sized file. But then leveldb code doesn't write ldb files to .ldbtmp and does rename, so in power loss cases, it's possible to end up with 0 sized ldb files).

Can you shed some light as to which ldb file is corrupt and why is it covered by the manifest?

670B3wI.aux.zip

@cmumford

This comment has been minimized.

Show comment
Hide comment
@cmumford

cmumford Jan 21, 2016

Contributor

The corrupt file is 001195.ldb - and it's an empty file. It is true that leveldb does not flush/sync/rename *.ldb files when writing, but it does do that when writing the MANIFEST - and that's what references the *.ldb files. The manifest is written afterwards, so this should ensure that the *.ldb files are safely on disk before being referenced.

So, yes; this could be a bug. It could be a hardware failure. It could be interference by another program (like antivirus/malware). etc. etc.

Have you been able to reproduce this? What version of leveldb? What OS?

Contributor

cmumford commented Jan 21, 2016

The corrupt file is 001195.ldb - and it's an empty file. It is true that leveldb does not flush/sync/rename *.ldb files when writing, but it does do that when writing the MANIFEST - and that's what references the *.ldb files. The manifest is written afterwards, so this should ensure that the *.ldb files are safely on disk before being referenced.

So, yes; this could be a bug. It could be a hardware failure. It could be interference by another program (like antivirus/malware). etc. etc.

Have you been able to reproduce this? What version of leveldb? What OS?

@cmumford cmumford added the bug label Jan 21, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment