subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Mikesell <>
Subject Re: Support for filesystem snapshots (?)
Date Mon, 02 Aug 2010 20:55:47 GMT
On 8/2/2010 3:46 PM, Vallon, Justin wrote:
> From: Stefan Sperling []
>> <stsp>  users asking interesting questions:
>> <stsp>  i dunno how fsfs behaves in face of an interrupted commit; whether
or not it needs to be rolled back
>> <danielsh>  if you haven't touched current than the rev file will never be
read and will be overwritten
>> <danielsh>  stsp: does that answer your question?
>> <stsp>  i think so
>> <stsp>  because the rev file of the following commit will have the same name
to move things into place onto
>> <danielsh>  write lock only for revprop change and commit
>> <danielsh>  :-)
>> Now, how does rsync, or a file-system snapshot, know to make sure that
>> 'current' is always copied first? Even if you copy 'current' first manually,
>> rsync might later overwrite it. But unless you use packing it's trivial to
>> fix the backup if it breaks, and all you risk is losing the most recent HEAD
>> revision, which you may not have gotten with a hotcopy anyway.
> When I speak of a filesystem snapshot, I mean an instantaneous copy of the volume (ala
NetApp, EMC, ZFS).  In this case, there is a guarantee that if we snap the new "current",
then we will also have the other files (assuming that they have been flushed, etc, by the
client).  Further, it sounds like (a) subsequent commits will not run into trouble because
of the partial commit, and (b) the repository will not be otherwise affected by a partial
> That means filesystem snapshots pass the transactional test.

Maybe - is there a guarantee that the app flushes to disk in the 
expected order?  Or do snapshots take the current dirty filesystem 
buffers into account?

   Les Mikesell

View raw message