[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Merge tracking: will SQLite make NFS sad?

From: Daniel Rall <dlr_at_collab.net>
Date: 2007-03-05 23:31:47 CET

On Mon, 05 Mar 2007, Malcolm Rowe wrote:

> On Mon, Mar 05, 2007 at 09:15:30AM -0500, Mark Phippard wrote:
> > On 3/5/07, David Glasser <glasser@mit.edu> wrote:
> > >My impression (which may be out of date) is that sqlite2 used only
> > >file-level locking (like fsfs), but sqlite3 uses byte-level locking.
> > >I don't know much about NFS, but this is certainly bad for AFS at
> > >least.
> I don't know about sqlite2, but yes, that's my understanding of sqlite3
> too. FSFS only uses whole-file byte-range locks (which are a special
> case of POSIX fcntl() locks).

My other mail on this thread explores the file locking with SQLite.

> > If the database writes are all being serialized at a higher level by fsfs
> > (meaning it ensures that only one transaction at a time is being written)
> FSFS ensures that only one transaction is being committed at one time -
> are you doing the SQLite writes under the fs-wide write-lock?

The SQLite writes happen by way of the call to
svn_fs_merge_info__update_index() in libsvn_fs_fs/fs_fs.c:commit_body()
(documented as "called with the FS write lock"), and occur immediately
before we update the 'current' file.

My fuzz-fuzz fu is weak, but I believe this means the answer is "yes".


> > does that insulate us from problems at all? Or does the fact that other
> > client might be reading the database mean that corruption could happen? I
> > would assume it at least means that incorrect answers could be returned.
> Hence my question.

  • application/pgp-signature attachment: stored
Received on Mon Mar 5 23:36:15 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.