On Thu, Feb 16, 2012 at 03:56:29AM +0200, Daniel Shahaf wrote: > Nico Kadel-Garcia wrote on Wed, Feb 15, 2012 at 19:41:57 -0500: > > On Wed, Feb 15, 2012 at 6:19 PM, Philip Martin > > <philip.mar...@wandisco.com> wrote: > > > Nico Kadel-Garcia <nka...@gmail.com> writes: > > > > > >> Unless you do a "sync" > > >> command, or various low level flush commands, you don't know that you > > >> write to disk has actually made it to the platter. > > > > > > Subversion does that. It uses fsync (plus fsync on directories on > > > Linux) before assuming data is on disk. > > > > So the risk is reduced, which is good. It lowers the window of > > vulnerability (between when a commit is published, and when the fsync > > occurs). This is actually good progamming. Not everyone who deals with > > real data is this thoughtful. > > There is no "window of vulnerability".
There is in the case where the operating system or disk lies to the application about data having been stored on platters. E.g. it depends on how long the OS blocks the application during fsync. Will it make the app wait all the way until the disk controller sent an acknowledgement interrupt for the write? Or will it allow the application to continue as soon as the buffer no cache no longer considers the buffer dirty because it issued a write? This descision is entirely up to the OS. What if the disk controller lies and sends the acknowledgement before the actual work has completed (e.g. it cached the write request and is going to get to it soon)? How can the OS know what the disk controller is really doing? Now, insert some network storage layer that runs on top of IP into the picture and you've got some more opportunities for things to go wrong. Now the request is passing through network stacks and possibly firewalls, and the network may treat a lost packet as collateral damage. I am not saying Subversion is careless. There is nothing Subversion can do about any of this. But these are things to consider when building a system for high reliability purposes. The systems are complex and the less complexity you've got the more reliability you tend to get.
