On 8/2/2010 3:46 PM, Vallon, Justin wrote:
From: Stefan Sperling [mailto:s...@elego.de]
<stsp>  users asking interesting questions: 
http://mail-archives.apache.org/mod_mbox/subversion-users/201008.mbox/%3c6ec02a00cc9f684daf4af4084ca84d5f01c40...@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
   lesmikes...@gmail.com

Reply via email to