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

Re: [PATCH] Fixing the FSFS corruption bug, again

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-10-02 23:24:38 CEST

On 10/2/06, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> Here's an updated patch to (hopefully) fix the FSFS corruption problem,
> this time using a method that works on NFS filesystems.
>
> See http://svn.haxx.se/dev/archive-2006-09/0078.shtml and issue #2467
> for background.
>
> Comments would be appreciated, as would test results from OS X or Windows.

This seems to work just fine on OS X and Linux, FWIW, but there's at
least one thing that worries me. The locking scheme used for managing
the per-txn stuff really could use some commenting, since I've been
staring at it for at least half an hour now trying to make sure I've
got it right.

Just to be clear, there's a single per-filesystem mutex that's used
within the with_txnlist_lock function to serialize access to both the
list of transactions and some of the data within the transactions. We
grab that lock, grab the flock, then note "hey, i've got it locked",
then drop the mutex. Later on when someone else tries to modify the
txn they'll be able to lock the per-filesystem mutex, but at that
point they'll see that someone else is modifying the txn, and error
out before they try to grab the flock? Other processes will simply
block when trying to flock.

I guess the part that confused me was how we've got a single per-fs
mutex, but per-txn lock files. In retrospect it makes sense, but it
was a bit weird at first. Other than that, this all seems fine, and I
think the confusion could be taken care of by some comments that sum
up the overall locking strategy, especially the fact that the
txn_list_lock ends up protecting both the list and the being_written
field.

Oh, and you've also got some mega-long lines in there that need to be
wrapped, but I'm sure you would have taken care of that before
committing.

-garrett

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 2 23:24:56 2006

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.