On 09/14/2011 11:27 AM, Anand Avati wrote:
On Wed, Sep 14, 2011 at 7:30 PM, Jeff Darcy <jdarcy@redhat.com mailto:jdarcy@redhat.com> wrote:
>> 1. Forward the write to all N replicas 2. If all N replicas >> indicate success, we're done 3. If any replica fails, add >> information about the failed request (e.g. file, offset, length) to >> journals on the replicas where it succeeded. First, I would not say that the file on the server where the write succeeded (there's no real primary in this architecture) is corrupt. It's just more up to date that on a server where the same write failed. The key here is that it can update its journal *locally* as part of the write itself. This would involve extra disk I/O but not extra network traffic.
I feel the above two paragraphs are not in sync.
Paragraph 1 says if all N replicas indicate success, we're done (i.e no more network calls. which means, no journal entries were made yet). -- (1)
Paragraph 2 says journals are local to the server as part of the write itself. But in anticipation of all writes succeeding, nothing journal entries are made along with the write. -- (2).
Yes, they are out of sync. In response to the concerns that Etsuji and others had raised, I moved the journal-entry creation back to the write; now only the change to the entry's status occurs later. I guess that's less optimistic than what I started with, but still more optimistic than current AFR. Note that the extra disk I/O is only for metadata; the write data itself will be available from the file at all relevant points, so it doesn't need to be written a second time (which would still be better than extra network round trips BTW).
My apologies for not being clearer that the description in the second paragraph represented a change. Once the discussion has settled a bit, I'll send out a second (and hopefully self-consistent) version.