Yes.
On Jun 19, 2014, at 1:47 PM, Theo Schlossnagle wrote:
> To be clear, you're considering a13160da8adeca96d80388cc77cb88ad5301aeaa the
> latest?
>
>
> On Thu, Jun 19, 2014 at 12:36 PM, Matthew Von-Maszewski
> wrote:
> Running repair now may have detected damage done to your data long ago
To be clear, you're considering a13160da8adeca96d80388cc77cb88ad5301aeaa
the latest?
On Thu, Jun 19, 2014 at 12:36 PM, Matthew Von-Maszewski
wrote:
> 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.
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/l
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
