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 <email@example.com> 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.
Received on Mon Mar 5 23:36:15 2007
- application/pgp-signature attachment: stored