RE: Support for filesystem snapshots (?)

From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
> 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 http://nfs.sourceforge.net/nfs-howto/ar01s05.html, 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 snapshots.

-- 
-Justin