RE: Support for filesystem snapshots (?)
From: Vallon, Justin <Justin.Vallon_at_deshaw.com>
Date: Mon, 2 Aug 2010 18:09:26 -0400
From: Les Mikesell [mailto:lesmikesell_at_gmail.com]
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
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.
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.
-- -JustinReceived on 2010-08-03 00:12:14 CEST
This is an archived mail posted to the Subversion Users mailing list.