Re: Merge tracking: will SQLite make NFS sad?

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".

http://svn.collab.net/viewvc/svn/branches/merge-tracking/subversion/libsvn_fs_fs/fs_fs.c?view=markup

> > 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.