Running repair now may have detected damage done to your data long ago. Repair reads every file and tests the CRC on every block in the file.
Two known issues might have caused the original corruption: https://github.com/basho/leveldb/wiki/mv-verify-compactions or https://github.com/basho/leveldb/wiki/mv-async-close Also, there is a bug in the 532bb commit that can cause level-0 files to be wrongly deleted. I suggest pulling the latest to get rid of that bug. Matthew On Jun 19, 2014, at 12:24 PM, Theo Schlossnagle <je...@omniti.com> wrote: > I'm using basho/leveldb as of commit: > 532bb6351e7835e862c8508520780bfc9d0c2b78 (no snappy) > > I have an issue with some small sized database... they claim corruption, but > when running a repair I have a nonsensical amount of sst's moved into "lost" > > Worse, the files moved to "lost" have very very old creation times (in > months). The system has been restarted successfully many times in the > interim, leading to more confusion. > > I'm looking for pointers to get to the bottom of this. It isn't critical > thatI recover this data, but it is critical that I don't see this manifest > when it does matter. > > Before repair: > > 40960 108441.log > 1 CURRENT > 0 LOCK > 3 LOG > 3 LOG.old > 92 MANIFEST-108439 > 469 sst_0 > 1 sst_1 > 188185 sst_2 > 4189331 sst_3 > 6343660 sst_4 > 1 sst_5 > 1 sst_6 > > After repair: > > 40960 108452.log > 1 CURRENT > 0 LOCK > 3 LOG > 3 LOG.old > 28 MANIFEST-108450 > 8221971 lost > 2362 sst_0 > 1 sst_1 > 188185 sst_2 > 2352071 sst_3 > 1 sst_4 > 1 sst_5 > 1 sst_6 > > > > -- > Theo Schlossnagle > > http://omniti.com/is/theo-schlossnagle > > _______________________________________________ > riak-users mailing list > riak-users@lists.basho.com > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
