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 22:09:26 GMT
From: Les Mikesell [] 
> On 8/2/2010 3:46 PM, Vallon, Justin wrote:
> > 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?

If the client or server filesystem buffers are dirty, then the application has not flushed
the data.  Therefore, the application should make no assumption about whether the data has
been written through to its final media.  What is critical is that (a) everything gets flushed,
then (b) current is updated, then (c) current is flushed.

This generalizes to:

1) Do whatever you want so long as it can be discarded and/or be written out of order
2) Flush everything
3) Write a flag saying that everything has been committed
4) Flush again

On the topic of whether dirty server-side buffers are in the snapshot, there are two reasons
the data could be dirty:

a) The client is in the middle of writing some data, the server is about to write it, and
the client is waiting.
b) The client wrote the data asynchronously, and the server can write it whenever it wants
(async write).

In either case, it would not be surprising for the data to be included in the snapshot or
excluded.  However, in neither case should the client have expected that the data be present
in the snapshot, since it was either in-progress or a delayed write.

All of this can get thrown out the window if the server decides to "lie".  See,
section 5.9, where it describes how the Linux async NFS export option can cause the NFS server
to lie when asked to fsync or flush-on-close.  The problem here is that the server might keep
the revs (part 1) in cache, while writing out the current file (part 3), leaving a corrupted
repository if the server fails.  So, this is a problem in general, not specific to filesystem


View raw message