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

Re: 2 users working on same file caused a change to be reverted rather than merged

From: Andreas Schweigstill <andreas_at_schweigstill.de>
Date: Wed, 18 Feb 2009 05:21:02 +0100


Toby Thain schrieb:
> This is a flaw of *all* RAID-1 systems, software or hardware
> (excepting the few in the high end that implement checksums).

No, it is only related to some OS which do some performance
optimizations. On Solaris one can set md_mirror:md_mirror_wow_flg=0x20
which disables performance optimization.

> It also risks integrity if the system suffers a sudden interruption
> during writing (e.g. powerfail, panic, etc).

That is another problem which can't be completely solved. But this
has nearly nothing to do with normal operation.

>> Nowadays these WOW problems "should" be non-existing but I am not
>> dure since when Linux soft-RAID handles them correctly.
> There is no solution; the flaw is inherent in the design. *Non-
> checksummed* RAID-1 cannot determine which side of the mirror holds
> valid data.

They just can't determine the valid mirror side in the case of an
interruption or for computing clusters which access the same disks.

And for normal use it is not important that both sides of the mirror
contain the same data also on short timescales. It is sufficient that
read operations on the same sector/block return consistent data.

> Sun's ZFS solves this problem entirely.

ZFS solves many problems, but the WOW problem was/is mainly present on
Solaris systems using the normal Sun Volume Manager with UFS.

Andreas Schweigstill

Dipl.-Phys. Andreas Schweigstill
Schweigstill IT | Embedded Systems
Schauenburgerstra├če 116, D-24118 Kiel, Germany
Phone: (+49) 431 53035-435, Fax: (+49) 431 53035-436
Mobile: (+49) 171 6921973, Web: http://www.schweigstill.de/
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-18 05:23:10 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.