On Tue, Mar 24, 2009 at 02:55:49PM +0100, Bert Huijben wrote:
> > -----Original Message-----
> > From: Stefan Sperling [mailto:stsp_at_elego.de]
> > Sent: dinsdag 24 maart 2009 14:21
> > To: dev_at_subversion.tigris.org
> > Subject: Re: svn commit: r36749 - trunk/subversion/libsvn_subr
> >
> > On Tue, Mar 24, 2009 at 06:03:48AM -0700, Bert Huijben wrote:
> > > Author: rhuijben
> > > Date: Tue Mar 24 06:03:48 2009
> > > New Revision: 36749
> > >
> > > Log:
> > > * subversion/libsvn_subr/sqlite.c
> > > (svn_sqlite__open): Switch sqlite synchronization off to make Sqlite
> > > performance workable on systems implementing full synchronization.
> > > Even with synchronization disabled Sqlite guarantees transactions
> over
> > > application crashes above the WC.1.0 level; and yournaling
> filesystems
> > > provide most of the other safety functions without this penalty.
> >
> > What does this mean for systems that don't have journalling file systems?
> > Do they lose those other safety functions? What safety functions are lost
> > exactly?
> >
> > What is "WC.1.0 level"? What thing can have or reach this level?
> > And is it something we can define or is it something defined internally
> > by sqlite?
> >
> > (I don't know much about sqlite so please excuse my ignorance).
>
> Currently Sqlite asks the OS after every partial write to wait for flushing
> the buffers on disk. This is implemented differently on diverse operating
> systems. On most linux filesystems this is +- a NO-OP (Filesystem determines
> it is not necessary because it has journaling support).
> On Windows this is exactly what it says and on MAC-OS it is somewhere in
> between unless you enable another sync pragma that is by default disabled.
>
> Without this safety net, that is designed to protect disk access errors in
> case of power failures and hardware breakage Sqlite is documented to be MUCH
> (Upto 50 times) faster, but in our current usage the difference is even
> bigger. (+- every record change is currently a transaction by itself).
>
>
> Over this OS synchronization layer Sqlite has 'normal' transaction support
> with atomic commits on about the same safety level as Mysql. This layer,
> without the safety net just disabled guarantees that the transactions are
> atomic over application crashes and virtually all other malfunctions.
>
> The rest of our datastore (pristine files, property access, normal file
> change detection) currently comes near these guarantees in this lowest
> security mode; so all layers above are just overkill.
OK, so with sqlite synchronization enabled we effectively disable disk
caches on some systems. In this light I am OK with your change.
We don't need to be safer than wc-1.0 already is.
Thanks for the explanation!
Maybe put a bit of this information in the comment?
Stefan
Received on 2009-03-24 15:04:40 CET