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.martin_at_wandisco.com> wrote:
> > > Nico Kadel-Garcia <nkadel_at_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.
Received on 2012-02-16 13:53:50 CET