On 16.02.2011 23:56, Blair Zajac wrote:
> On 02/16/2011 02:15 PM, Philip Martin wrote:
>> Blair Zajac<blair_at_orcaware.com> writes:
>>
>>> On 02/16/2011 08:44 AM, Philip Martin wrote:
>>>> So if the timing is just right it's possible for one Apache process to
>>>> start writing the transaction, for that process to stop, and for
>>>> another
>>>> process to take over the commit. WANdisco observed problems on FSFS
>>>> where the transaction is synced at the end of the commit, not for each
>>>> http request. What ends up in the transaction probably depends on the
>>>> details of the kernel memory and disk caching, the system load, the
>>>> underlying OS filesystem, etc.
>>>
>>> This is a concern when the repository is hosted on an NFS or other
>>> network attached storage? If all the Apache processes are on the same
>>> system, then I wouldn't expect any issues.
>>
>> I don't agree. Just because the process has written data to a file
>> doesn't mean it will appear on disk if the process is killed. We would
>> need to call fsync before acknowledging each request to guarantee that
>> the data was permanent. We don't do that. So the first apache process
>> writes the first part of the transaction, gets killed, and a second
>> apache process takes over an writes the rest of the transaction. Only
>> the second process runs fsync. Some, or all, of the data written by the
>> first process may be missing, so if/when the transaction is finally
>> committed the result is not well defined.
>
> OK. You're trying to handle a unclean shutdown.
>
> In this case, sounds like you want to get transactional with the
> transaction :)
>
> I think you would want to throw away the transaction entirely. Could
> leave a dirty file there and if a process sees with when it starts to
> modify the transaction, it bails.
Just please don't anyone try to reinvent the proverbial wheel when doing
this. Look for the several workable examples of how such crash-safe disk
commits are done and pick one.
Hint: all of them need an fsync somewhere.
-- Brane
Received on 2011-02-17 00:01:41 CET