You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by iv...@apache.org on 2013/05/17 15:32:56 UTC
svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Author: ivan
Date: Fri May 17 13:32:56 2013
New Revision: 1483795
URL: http://svn.apache.org/r1483795
Log:
* STATUS: Nominate r1483781 for backport to 1.8.0.
Modified:
subversion/branches/1.8.x/STATUS
Modified: subversion/branches/1.8.x/STATUS
URL: http://svn.apache.org/viewvc/subversion/branches/1.8.x/STATUS?rev=1483795&r1=1483794&r2=1483795&view=diff
==============================================================================
--- 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 Windows:
+ http://svn.haxx.se/dev/archive-2013-05/0245.shtml
+ Justification:
+ Repository corruption. Regression from 1.6.x
+ Votes:
+ +1: ivan
+
Approved for 1.8.1 or when we release a new RC:
===============================================
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Ben Reser <be...@reser.org>.
On Fri, May 17, 2013 at 7:55 AM, Philip Martin
<ph...@wandisco.com> wrote:
> 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.
Agreed, the worst thing that could result from this change is that it
hurts performance on Windows. I'm inclined to let this in without
restarting the soak. We've already included a couple other small code
changes.
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Branko Čibej <br...@wandisco.com>.
On 18.05.2013 11:52, Bert Huijben wrote:
> We do this because *some of* the callers want this behavior... But all others get the same pain as well.
>
> And then the rename function can just perform a dumb file copy without any precautions when we are crossing a disk boundary.
>
>
> This behavior belongs in a function with a specific purpose: atomic renames of new files.
> Not in a simple file creation function that is used in many places.
This I can certainly agree with. The question remains, however: what can
we do /now/ in order to avoid the potential corruption? I propose we
have two options: use the fix Ivan came up with and optimize it later,
or delay 1.8.0 until what you propose can be implemented.
Personally I don't have a problem with the latter approach, but we know
it could take weeks and would definitely restart the soak. As far as I
know, we don't have any performance data that could help us decide.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
RE: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Branko Čibej [mailto:brane@wandisco.com]
> Sent: zaterdag 18 mei 2013 10:52
> To: Subversion Development
> Subject: Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
>
> On 18.05.2013 08:55, Bert Huijben wrote:
> > I see all those easy +1’s on other operating systems...
> > I assume you all reproduced the problem on Windows???
>
> What the blazes are you going on about, Bert? Justin's +1 was for
> putting repository integrity before performance. That has nothing at all
> to do with any specific platform.
>
> > Maybe also on actual hardware instead of a VM (with a VM harddisk
> > emulation infrastructure with different powerfail handling)?
> >
> > I still see no prove that the symptoms are not in this category!
>
> Ivan's analysis of the failure mode is correct, and it has nothing to do
> with disks, emulated or otherwise, because it is a side effect of what
> happens before the data hits the disk driver layer.
>
> > But if you check the sqlite research: which other operating systems
> > provide the same guarantees on power failure at the cost of a lot of
> > performance?
>
> The SQLite docs clearly spell out what happens if you don't turn on the
> whole sync'd WAL. The Subversion repository is not an application-level
> persistent store, it's a centralized repository that we /know/ has to be
> as robust as we can make it.
But why do we perform the same flush for 3* on a tempfile for each property conflict that is postponed in 'svn'?
For files that aren't read back unless the user uses interactive conflict resolution?
This kind of behavior belongs in FSFS... well designed, not in a simple 'cheap' function to write a string to a file.
I 100% agree that FSFS should be robust...
But if we add a flush after every file write in our code nobody will use Subversion as it is so insanely slow... And we wouldn't resolve the problem we thought of resolving.
Getting proper revision commit handling requires a careful design and applying that. Not adding explicit flushes in low level functions that are used for more code paths than these.
The careful flush is needed at the time of committing a revision. Probably two or three times max during a revision creation. This flush will require writing to two MFT's (Master File Tables) and the file itself so probably at least 6 harddisk spin cycles each (and more if there are other operations waiting for the MFT to be completed stable). If the disk is not locally but on another Windows system the CIFS protocol will transfer the ensurance further and the delay may be much larger.
If we apply this same flush to the average tempfile that isn't even referenced from other files we'll trash performance for nothing. And that is exactly what you get if you do this low level in io.c, without also handling the move/rename in the same function.
We do this because *some of* the callers want this behavior... But all others get the same pain as well.
And then the rename function can just perform a dumb file copy without any precautions when we are crossing a disk boundary.
This behavior belongs in a function with a specific purpose: atomic renames of new files.
Not in a simple file creation function that is used in many places.
Bert
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Branko Čibej <br...@wandisco.com>.
On 18.05.2013 08:55, Bert Huijben wrote:
> I see all those easy +1’s on other operating systems...
> I assume you all reproduced the problem on Windows???
What the blazes are you going on about, Bert? Justin's +1 was for
putting repository integrity before performance. That has nothing at all
to do with any specific platform.
> Maybe also on actual hardware instead of a VM (with a VM harddisk
> emulation infrastructure with different powerfail handling)?
>
> I still see no prove that the symptoms are not in this category!
Ivan's analysis of the failure mode is correct, and it has nothing to do
with disks, emulated or otherwise, because it is a side effect of what
happens before the data hits the disk driver layer.
> But if you check the sqlite research: which other operating systems
> provide the same guarantees on power failure at the cost of a lot of
> performance?
The SQLite docs clearly spell out what happens if you don't turn on the
whole sync'd WAL. The Subversion repository is not an application-level
persistent store, it's a centralized repository that we /know/ has to be
as robust as we can make it.
> We are talking about flushing the NTFS journal to ensure everything
> for a single file is flished. Something which in multi user systems
> such as *nix really requires root permissions as it allows trashing
> performance for the entire system.
Excuse me? fsync() requires root? That's a new one.
> Safety is a nice property, but you can’t get it via just these
> flushes. Usability is also important. And the rest of the system needs
> the same power safety security principles for these flushes to make
> sense. *And then only in critical places, not after every small
> tempfile write.*
> **
> *E.g. part of the design. Not as part of a low level function.*
Are you saying that it's OK to have a known repository corruption for
the sake of not having users breathe down our necks about performance on
Windows?
> If we are going this way we can stop all the fsfs v2 development and
> optimizations for our biggest market. If we go this way we are going
> to be several orders of magnitude slower anyway for fixing a few of
> our power loss issues. There is no use of shaving a few % in other places.
>
>
> Not every filesystem has the performance characteristics of ext2; a
> system without journal.
> This is moving back to the simplistic “Windows is slow” world we had
> around 1.5 before I joined the development.
So why, in your opinion, is it OK to flush the file buffers on every
platform /except/ Windows? Are you saying that sysadmins on other
systems don't use journalled filesystems?
(Interestingly enough, that /is/ the case when we're talking about
storage for databases such as Oracle or Postgres, which have their own
journalling and logging built in. But a Subversion repository doesn't
even come close to that level of robustness on its own.)
> Looking at the number of corruptions reported over the past 4 years.
> How many users would be happier if the repository and/or working copy
> would be something like 400% slower to make it ‘somewhat less likely
> to corrupt on power failure’?
You're talking through your hat. You do not have a single data point
that supports your 400%, and moreover you haven't the any data about the
relative importance of Windows as a Subversion /server/. But that's all
beside the point.
Subversion's promise from day one is that it will not lose data (barring
bugs). Ivan fixed a bug that can cause data loss. It's as simple as
that. Moreover, the bug was, I suspect, caused by a misguided attempt at
improving Windows performance without considering the consequences.
You know as well as anyone else that we could make FSFS /much/ faster if
we didn't worry about atomically installing revision files. But
performance has always been secondary to robustness, in both the server
side /and/ the working copy.
Instead of screaming at people about performance loss, a more
constructive approach would be to propose an alternative solution that
fixes the same bug differently, but just as completely.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Sat, May 18, 2013 at 10:55 AM, Bert Huijben <be...@qqmail.nl> wrote:
> I see all those easy +1’s on other operating systems...
> I assume you all reproduced the problem on Windows???
>
> Maybe also on actual hardware instead of a VM (with a VM harddisk emulation
> infrastructure with different powerfail handling)?
>
> I still see no prove that the symptoms are not in this category!
>
Original customer report was about failure on real hardware, not VM.
>
> But if you check the sqlite research: which other operating systems provide
> the same guarantees on power failure at the cost of a lot of performance?
>
> We are talking about flushing the NTFS journal to ensure everything for a
> single file is flished. Something which in multi user systems such as *nix
> really requires root permissions as it allows trashing performance for the
> entire system.
>
> Safety is a nice property, but you can’t get it via just these flushes.
> Usability is also important. And the rest of the system needs the same power
> safety security principles for these flushes to make sense. And then only in
> critical places, not after every small tempfile write.
>
> E.g. part of the design. Not as part of a low level function.
I agree with you that flushing should be part of the design, not of
low level function. But that how current code works and you changed
behavior of low-level function in r1082451. Even more: you made
behavior of low-level function platform-depended. That's why I
reverted this change. Proper fix should be introduce
svn_io_write_atomic() and svn_io_atomic_stream_create() with full sync
flag. And also add explicit DISK_FLUSH flag to svn_io_write_unique()
instead of making behavior depended of DELETE_WHEN flag.
> If we are going this way we can stop all the fsfs v2 development and
> optimizations for our biggest market. If we go this way we are going to be
> several orders of magnitude slower anyway for fixing a few of our power loss
> issues. There is no use of shaving a few % in other places.
>
I don't think that FSFS performance is important thing. Development of
our own high-performance database with access from multiple process is
not what Subversion developers should be focused. Moves and merges are
much more important.
(And I don't say about our own cache server :)
> Not every filesystem has the performance characteristics of ext2; a system
> without journal.
> This is moving back to the simplistic “Windows is slow” world we had around
> 1.5 before I joined the development.
>
You that 1.5 slowness had different reasons: multiple .svn and our own
entries file.
> Looking at the number of corruptions reported over the past 4 years. How
> many users would be happier if the repository and/or working copy would be
> something like 400% slower to make it ‘somewhat less likely to corrupt on
> power failure’?
>
I agree that working copy corruption are not so important, but they
are important. Do you ready to lose several complex changes in source
code for 400% performance win? You can always open Hard Disk
properties, then Polices and check "Turn off Windows write-cache
buffer flushing on the device" and performance even you're ready to
trade it for working copy corruptions.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Bert Huijben <be...@qqmail.nl>.
I see all those easy +1’s on other operating systems...
I assume you all reproduced the problem on Windows???
Maybe also on actual hardware instead of a VM (with a VM harddisk emulation infrastructure with different powerfail handling)?
I still see no prove that the symptoms are not in this category!
But if you check the sqlite research: which other operating systems provide the same guarantees on power failure at the cost of a lot of performance?
We are talking about flushing the NTFS journal to ensure everything for a single file is flished. Something which in multi user systems such as *nix really requires root permissions as it allows trashing performance for the entire system.
Safety is a nice property, but you can’t get it via just these flushes. Usability is also important. And the rest of the system needs the same power safety security principles for these flushes to make sense. And then only in critical places, not after every small tempfile write.
E.g. part of the design. Not as part of a low level function.
If we are going this way we can stop all the fsfs v2 development and optimizations for our biggest market. If we go this way we are going to be several orders of magnitude slower anyway for fixing a few of our power loss issues. There is no use of shaving a few % in other places.
Not every filesystem has the performance characteristics of ext2; a system without journal.
This is moving back to the simplistic “Windows is slow” world we had around 1.5 before I joined the development.
Looking at the number of corruptions reported over the past 4 years. How many users would be happier if the repository and/or working copy would be something like 400% slower to make it ‘somewhat less likely to corrupt on power failure’?
Bert
Sent from Windows Mail
From: Justin Erenkrantz
Sent: Saturday, May 18, 2013 6:00 AM
To: Ivan Zhakov
Cc: Bert Huijben; C. Michael Pilato; Philip Martin; Branko Čibej; Subversion Development
On Fri, May 17, 2013 at 5:58 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
Yes, this will be good improvement anyway, but I think repository
integrity should be first goal.
+1! =P -- justin
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
On Fri, May 17, 2013 at 5:58 PM, Ivan Zhakov <iv...@visualsvn.com> wrote:
> Yes, this will be good improvement anyway, but I think repository
> integrity should be first goal.
>
+1! =P -- justin
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Sat, May 18, 2013 at 12:55 AM, Bert Huijben <be...@qqmail.nl> wrote:
>> -----Original Message-----
>> From: Ivan Zhakov [mailto:ivan@visualsvn.com]
>> Sent: vrijdag 17 mei 2013 17:03
>> To: C. Michael Pilato
>> Cc: Philip Martin; Branko Čibej; dev@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 <cm...@collab.net>
>> wrote:
>> > On 05/17/2013 10:55 AM, Philip Martin wrote:
>> >> Branko Čibej <br...@wandisco.com> writes:
>> >>
>> >>> On 17.05.2013 15:32, ivan@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
>> Windows:
>> >>>> + 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.
Yes, this will be good improvement anyway, but I think repository
integrity should be first goal.
Also please note that FlushFileBuffers doesn't perform *full* sync: it
flushes data only for one file.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
RE: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Ivan Zhakov [mailto:ivan@visualsvn.com]
> Sent: vrijdag 17 mei 2013 17:03
> To: C. Michael Pilato
> Cc: Philip Martin; Branko Čibej; dev@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 <cm...@collab.net>
> wrote:
> > On 05/17/2013 10:55 AM, Philip Martin wrote:
> >> Branko Čibej <br...@wandisco.com> writes:
> >>
> >>> On 17.05.2013 15:32, ivan@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
> Windows:
> >>>> + 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)
Bert
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Fri, May 17, 2013 at 6:59 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 05/17/2013 10:55 AM, Philip Martin wrote:
>> Branko Čibej <br...@wandisco.com> writes:
>>
>>> On 17.05.2013 15:32, ivan@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 Windows:
>>>> + 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.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/17/2013 10:55 AM, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> On 17.05.2013 15:32, ivan@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 Windows:
>>> + 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.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Philip Martin <ph...@wandisco.com>.
Branko Čibej <br...@wandisco.com> writes:
> On 17.05.2013 15:32, ivan@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 Windows:
>> + 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.
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Branko Čibej <br...@wandisco.com>.
On 17.05.2013 15:58, Ivan Zhakov wrote:
> On Fri, May 17, 2013 at 5:53 PM, Branko Čibej <br...@wandisco.com> wrote:
>> On 17.05.2013 15:32, ivan@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 Windows:
>>> + 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?
>>
> I consider this a blocker. I'm also proposed to backport to 1.7.x and
> I think we cannot release 1.8.0 with regression against latest 1.7.x.
>
> But problem that we have other places with the same problem in FSFS
> code. In setrevprop code for example. I'm going to find them and fix.
Understood. Thanks for finding this -- and BTW I agree with your
analysis, it reminded me that I saw similar behaviour (file renamed
after power cycle, but contents gone) years ago on a completely
unrelated project.
In other words, +1 for fixing this in 1.8.0.
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Fri, May 17, 2013 at 5:53 PM, Branko Čibej <br...@wandisco.com> wrote:
> On 17.05.2013 15:32, ivan@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 Windows:
>> + 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?
>
I consider this a blocker. I'm also proposed to backport to 1.7.x and
I think we cannot release 1.8.0 with regression against latest 1.7.x.
But problem that we have other places with the same problem in FSFS
code. In setrevprop code for example. I'm going to find them and fix.
--
Ivan Zhakov
CTO | VisualSVN | http://www.visualsvn.com
Re: svn commit: r1483795 - /subversion/branches/1.8.x/STATUS
Posted by Branko Čibej <br...@wandisco.com>.
On 17.05.2013 15:32, ivan@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 Windows:
> + 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?
-- Brane
--
Branko Čibej
Director of Subversion | WANdisco | www.wandisco.com