On 8/2/2010 3:46 PM, Vallon, Justin wrote:
> From: Stefan Sperling [mailto:stsp_at_elego.de]
>> <stsp> users asking interesting questions: http://mail-archives.apache.org/mod_mbox/subversion-users/201008.mbox/%3C6EC02A00CC9F684DAF4AF4084CA84D5F01C40CD7@DRMBX3.winmail.deshaw.com%3E
>> <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.
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
lesmikesell_at_gmail.com
Received on 2010-08-02 22:56:28 CEST