RE: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
> -----Original Message-----
> From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
> Sent: vrijdag 17 mei 2013 17:03
> To: C. Michael Pilato
> Cc: Philip Martin; Branko Čibej; dev_at_subversion.apache.org
> Subject: Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
> On Fri, May 17, 2013 at 6:59 PM, C. Michael Pilato <cmpilato_at_collab.net>
> > On 05/17/2013 10:55 AM, Philip Martin wrote:
> >> Branko Čibej <brane_at_wandisco.com> writes:
> >>> On 17.05.2013 15:32, ivan_at_apache.org wrote:
> >>>> --- subversion/branches/1.8.x/STATUS (original)
> >>>> +++ subversion/branches/1.8.x/STATUS Fri May 17 13:32:56 2013
> >>>> @@ -124,6 +124,14 @@ Candidate changes:
> >>>> Votes:
> >>>> +1: stefan2 (for 1.8.1)
> >>>> +* r1483781
> >>>> + Fix FSFS repository corruption on power or network disk failure on
> >>>> + http://svn.haxx.se/dev/archive-2013-05/0245.shtml
> >>>> + Justification:
> >>>> + Repository corruption. Regression from 1.6.x
> >>>> + Votes:
> >>>> + +1: ivan
> >>>> +
> >>> Is this considered a blocker? Should we roll RC3 next week and restart
> >>> the soak period?
> >> We should put this into 1.8.0 but I don't think it is a destabilizing
> >> change so we don't need to restart the soak.
> > I agree. Soak time extensions are tied to the complexity of the change, not
> > the severity of the bug fixed.
> I agree this change is pretty simple and actually it just reverts
> Subversion to 1.6.x behavior, but there are other places with similar
> issue and they may require more complicated fix. I'm working on them.
If this and the future followups are going to have a huge performance impact we should probably make the full fsync option configurable for those who have a battery backed up storage.
(Looking at the current callers I don't think this is necessary. I think the original performance problem was mostly in the loggy handling)
Received on 2013-05-17 22:56:13 CEST
This is an archived mail posted to the Subversion Dev