1115 commits this week - Page 2 May 19, 2019 - May 26, 2019

Disable partial writes for the VolatileDB q-s-m tests

The model for the VolatileDB used in the q-s-m tests predicts the outcome of each operation based on the Errors that will be simulated. This worked out okay for putBlock, because it just called hPut once. We could just look in the Errors to see whether the first call to hPut would result in a simulated error.

With partial writes the story changes, because one call to hPut now potentially results in multiple calls to hPutSome. If we simulate a partial read for the first call to hPutSome, a second call might be needed to read the remaining bytes. If that is partial too, another call may be needed, and so on. It is hard to predict how many calls will be needed, because we would have to know how many bytes to write, and how many bytes have been written by each partial write.

The partial writes alone are not really a problem, it is the combination with a simulated error that is a problem. If we simulate an error for the nth call to hPutSome where n > 1, we don’t know whether it will actually be thrown or not, because we don’t know how many calls to hPutSome will be needed. So in the model we can’t predict whether the operation will succeed or not and the model will get out of sync with the real implementation.

For this reason, we just disable partial writes for the VolatileDB q-s-m tests (for now).

We already know that hPut (and its variants) deal with it correctly, since it works fine in the ImmutableDB q-s-m tests that do simulate partial writes.

Eventually, we want to stop predicting precisely whether an operation should fail based on the simulated errors in the VolatileDB, because it is very brittle. When that is done, we can enable partial writes here again.