[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: Toby Thain <toby_at_telegraphics.com.au>
Date: Tue, 17 Feb 2009 09:10:41 -0500

On 16-Feb-09, at 7:22 AM, Andreas Schweigstill wrote:

> Hello!
>
> Jan Hendrik schrieb:
>> Funny thing though: it only happens when the files already exist
>> on the Linkstation, any "new" file invariably gets the timestamp
>> it has on the local machine.
>
> There are several ways to write to an existing file. Many editors
> use a scheme where they first rename the old file to a temporary
> file, then they write their buffer contents to a new file which gets
> the old filename, and finally removes the old file with the temporary
> filename. This way it is assured that the file can be completely
> erased because of a program crash or network problem. In such cases
> the user would at least find the old file. When copying the original
> file attributes after successfully writing the new file probably
> also the old timestamp gets copied. This can either be related to
> some caching issues or just a simple programming error.

In this connection, Apple's HFS has an atomic file swap operation.

>
> On some RAID systems there is also a "feature" which is called
> WOW (write on write) problem. When a block gets twice in a short
> time to a mirrored disk it can happen that write operation 1 gets
> executed on mirropr 1 first and on mirror 2 afterwards. Write op. 2
> gets executed the other way. Due to this race condition there
> can be inconsistent states on the mirrors. Similar race conditions
> on mirrored disks can occur when write and read operations are
> interleaved.

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

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

>
> 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.

Sun's ZFS solves this problem entirely.

--Toby

>
> Regards
> 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/
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?
> dsForumId=1065&dsMessageId=1170400
>
> To unsubscribe from this discussion, e-mail: [users-
> unsubscribe_at_subversion.tigris.org].

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=1179050

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-02-17 15:11:38 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.