ccing vinzvault ml since question is generally applicable there
On Mon, 2010-05-10 at 11:11 -0400, Jeff Darcy wrote:
One of the things that I was surprised not to see in your list of
requirements is consistency. I know that you don't need instantaneous
fine-grain serializable consistency, but it seems like there still has
to be some assurance that an instantiated image won't be subject to
arbitrary data-retrieval failures or staleness even though the image was
written somewhere else quite recently with an unknown network
environment in between. As soon as there's a need for any level of
consistency at all, there's an issue of how to prevent/avoid conflicts
or reconcile results after they've occurred - e.g. Hinted Handoff, Read
Repair, and Anti-Entropy in the Dynamo/Cassandra model - without
creating a bottleneck at the coordination point(s). An image-storage
system that's "best effort" and either fails or delivers incorrect
(stale) data under conditions that are impossible to predict or to
identify post-mortem might not be very broadly accepted among the people
who have thousands of machines to look after. Given enough machines and
enough time, even exotic failures do occur. Do you have some thoughts
on what easily-checked rules vinzvault will apply to ensure data
consistency (and BTW integrity as well)?
As there is only one writer in every case, a simple lamport time stamp
would do the trick. The reason those full database systems you mention
have all that complicated consistency management is because they
potentially have multiple writers. With multiple writers, after a
failure during an update, a consistent view must be created out of the
mess. With one writer, the worst case that could happen is that *some*
of the blocks were not written. This happens with normal storage in a
block system all the time during failure and is well tolerated by
journal filesystems.
Regards
-steve