[snip]
>
> The situation hasn't moved anywhere since the original messages back
> in Decemeber, I'm afraid. It's on the list of things I'd really like to
> fix, but the fact that it's hard to fix coupled with the fact that we
> could never track down the real cause or a reproduction means that
> it's not gone anywhere.
I'd like to fix this too, but my cycles for any sort of extracurricular development have been non-existent lately. I hope that changes, but I don't see it happening before September. :-(
>
> > We actually have seen the repository corruption number of times now
> (5
> > times till now) and want to get over with this problem ASAP.
> >
>
> One thing you could check is the version of APR you're using. So far,
> we only have reports of this problem occurring with APR < 0.9.7, and I did
> hypothesize at the time that this was possibly due to (or excarberated by)
> the fact that APR 0.9.6 and below don't report write errors on buffered
> files at all. Of course, APR 0.9.7 was still fairly new then, so it
> might also just be a coincidence. Then again, John mentions that he's
> not seen the problem as much recently, so perhaps not?
The number of messages that I've seen have definitely thinned out. However, I'm not as diligent as I used to be about scanning the users@ list (there's just too much volume, so unless it has a good subject, I might overlook it). The other side is that my script to help fix the problem is out there now. I don't know how many people are fixing the issue themselves. *shrug* I'm not sure everyone was using less than 0.9.7...
>
> The other things we'd noted are that this seemed to only be a problem for
> mod_dav_svn, and that it seemed like it might be related to problems
> writing to the disk. Again, our sample size is probably too small to
> draw conclusions, but if you can run some tests on the disk, that might
> not be a bad idea.
I definitely think it's a mod_dav_svn problem. svnserve uses a single process/thread to perform all writes to the rev prop file, whereas mod_dav_svn is sitting on top of a huge asynchronous request framework that can shove requests into entirely different processes. FWIW, I think this related to the concerns that Sussman brought up on the list recently. I intended to sit down and walk through mod_dav_svn, but not having much time coupled with the fact that there are only a few experts to bounce questions off of, means that it isn't getting done.
>
>
> As far as fixing it goes, the right fix is probably to only use a single
> file handle per revprop file, open for the lifetime of the transaction
> (or transaction root, actually).
/me agrees.
> This probably depends upon someone writing some mechanism to associate
> open FSFS transactions with arbitrary user-data (in this case, the
> file handle to use for the revprop file).
>
> I originally posted a conceptual patch that added the information as
> library-private data associated with a transaction object (I think),
> but this was rejected because it didn't prevent the problem (or may have
> caused problems, I forget) if the same transaction was opened via two
> different filesystem (svn_fs_t) objects. (There were some other reasons
> as well, see http://svn.haxx.se/dev/archive-2005-12/0571.shtml.)
>
> One possible solution that I was thinking about a week or so ago might
> be to create a map of { FS GUID, TXN ID => { stuff } }, but I'm concerned
> about whether we could race between creating the transaction (essentially
> an on-disk operation) and creating an entry in the map (purely a memory
> operation). Also, the map would have to maintain a reference-count of
> open transaction roots so that the handles were closed when the last
> reference was released.
>
> Brane committed some code fairly recently (for BDB 4.4 support) that
> looked like it did something similar, and I've been meaning to take a
> look at that. But it definitely wasn't trivial.
-John
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue May 30 12:32:44 2006