On 16.02.2011 23:56, Blair Zajac wrote: > On 02/16/2011 02:15 PM, Philip Martin wrote: >> Blair Zajac<bl...@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
