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

Re: svn commit: r33724 - branches/fsfs-pack/subversion/libsvn_fs_fs

From: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Sat, 18 Oct 2008 06:55:07 -0500

Hyrum K. Wright wrote:
> Greg Stein wrote:
>> Since you've already added sqlite, then you can simply go another
>> step: put the revprops in there. (I'd suggest as a separate dev effort
>> tho)
>
> That was my thought exactly (same with the fsfs locks storage, too). My only
> concerns are scalability and consistency on something like NFS. If we lose data
> from the rep-cache sqlite database, that doesn't impact the correctness of the
> repository. If something happens to revprops, it's a different story.
>
> Is there any reason to be concerned about using SQLite to store first class data
> in the repository?

To answer my own question (from http://www.sqlite.org/faq.html#q5):
SQLite uses reader/writer locks to control access to the database. (Under
Win95/98/ME which lacks support for reader/writer locks, a probabilistic
simulation is used instead.) But use caution: this locking mechanism might not
work correctly if the database file is kept on an NFS filesystem. This is
because fcntl() file locking is broken on many NFS implementations. You should
avoid putting SQLite database files on NFS if multiple processes might try to
access the file at the same time.

Now, we currently make less-than-perfect concurrency guarantees about revprop
editing anyway, so we may not have problems, but I can see this coming back to
bite us.

Then again, I may be worrying about nothing at all. :)

-Hyrum

Received on 2008-10-18 13:55:29 CEST

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.