Stefan Sperling wrote on Thu, Feb 16, 2012 at 13:53:04 +0100: > 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. >
Stefan, you're correct, it would have been more accurate for me to say "There is no window of vulnerability if specific system calls that Subversion uses fulfill their contract". It's just that getting to this level of detail seemed to be more hair-splitting than was necessary for me to rebut Nico's point. Thanks for clarifying. > > 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.
