subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vallon, Justin" <Justin.Val...@deshaw.com>
Subject RE: Support for filesystem snapshots (?)
Date Tue, 03 Aug 2010 15:43:22 GMT
> From: Les Mikesell [mailto:lesmikesell@gmail.com] 
> 
> A filesystem snapshot should present exactly the same scenario as a machine that 
> lost power or crashed for some similar reason at that moment, so the question 
> boils down to whether subversion can recover sensibly from a crash at any point. 
>   The fsync's are going to be the critical thing for ordering operations at the 
> disk level, however there is no guarantee how much of the fsync operation might 
> have completed when a crash or snapshot happens.

...and therefore applications (should) make no assumptions about the order of writing, or,
in the case of a crash, what data actually was written.

In generally, atomic updates have three phases: prepare, commit, apply.  In prepare, all changes
are written in a manner that either does not touch the main data (journal), or can be undone.
 In commit, an atomic write marks the prepared data as committed.  In apply, changes written
in the prepare phase are applied to the main data if required (ie: journal entries are "replayed"
to the main database).

The only atomic requirement here is that after prepare, we can flush everything (order is
not important) and the commit phase can be written atomically.  For example, the db/current
file is a integer string.  Since that file fits in a single disk block, there is no chance
that an update to db/current does not leave either the old or the new contents in the file.

-- 
-Justin



Mime
View raw message