subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vallon, Justin" <>
Subject RE: Support for filesystem snapshots (?)
Date Mon, 02 Aug 2010 20:46:58 GMT
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 commit.

That means filesystem snapshots pass the transactional test.

rsync does not pass this transactional test due to order-of-copying.  rsync with some "current"-first
logic would pass the test, but then we might as well use the hot-backup script.


View raw message