
On Tue, Mar 28, 2017 at 8:26 PM, Lee Clagett via Boost
This is simulating a write I/O error, not a power failure. Even with the assumption that a returned `fsync` has fully stored the data on disk, the recovery algorithm could be opening a log file which called `write` but never returned from `fsync`. That file could have enough "space" for a bucket, but lack the proper contents of the bucket itself. There is an inherent race between writing and the completion of an `fsync` that will go unnoticed by the current recovery algorithm on some filesystem configurations.
Okay, I can almost understand what you're saying. Perhaps a bit more guidance would help. Can you walk me through the scenario you're describing, making reference to the current commit algorithm? Its here: https://github.com/vinniefalco/NuDB/blob/master/include/nudb/impl/basic_stor... My goals is to improve the fail_file used in the tests to capture your case. Thanks