Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Date: Tue, 3 Aug 2010 14:25:37 +0200
From: Vincent Lefevre <vincent-svn@vinc17.net>
To: users@subversion.apache.org
Subject: Re: Support for filesystem snapshots (?)
Message-ID: <20100803122537.GH7288@prunille.vinc17.org>
Mail-Followup-To: users@subversion.apache.org
References: 
 <6EC02A00CC9F684DAF4AF4084CA84D5F01C40CB5@DRMBX3.winmail.deshaw.com>
 <20100802161739.GI3967@ted.stsp.name>
 <4C56F278.9030904@gmail.com>
 <6EC02A00CC9F684DAF4AF4084CA84D5F01C40CBC@DRMBX3.winmail.deshaw.com>
 <20100802175621.GL3967@ted.stsp.name>
 <6EC02A00CC9F684DAF4AF4084CA84D5F01C40CD7@DRMBX3.winmail.deshaw.com>
 <20100802202736.GO3967@ted.stsp.name>
 <6EC02A00CC9F684DAF4AF4084CA84D5F01C40CE1@DRMBX3.winmail.deshaw.com>
 <4C5730D3.8060507@gmail.com>
 <6EC02A00CC9F684DAF4AF4084CA84D5F01C40CEE@DRMBX3.winmail.deshaw.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <6EC02A00CC9F684DAF4AF4084CA84D5F01C40CEE@DRMBX3.winmail.deshaw.com>
User-Agent: Mutt/1.5.20-6088-vl-r38367 (2010-07-31)

On 2010-08-02 18:09:26 -0400, Vallon, Justin wrote:
> If the client or server filesystem buffers are dirty, then the
> application has not flushed the data.

There can be a flush at the application level (e.g. fflush() function
in C), but this doesn't mean that the flush is also done at the
file system level (physically), in particular with NFS. FYI, the
fflush(3) Linux man page says:

NOTES
  Note that fflush() only flushes the user space buffers provided by the
  C library.  To ensure that the data is physically stored on  disk  the
  kernel  buffers  must  be  flushed  too,  for example, with sync(2) or
  fsync(2).

But even sync() may not be sufficient:

BUGS
  According  to  the standard specification (e.g., POSIX.1-2001), sync()
  schedules the writes, but may return  before  the  actual  writing  is
  done.   However, since version 1.3.20 Linux does actually wait.  (This
  still does not guarantee  data  integrity:  modern  disks  have  large
  caches.)

Ditto for fsync:

  If  the  underlying hard disk has write caching enabled, then the data
  may not really be on permanent  storage  when  fsync()  /  fdatasync()
  return.

> 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.

I don't think this can be guaranteed just by looking at the application
code. Only the kernel and the filesystem implementation can document
whether the system calls are taken into account as expected.

Note: using fcntl locking (possibly in addition to other methods) can
also be useful.

[...]
> 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.

Yes.

-- 
Vincent Lef�vre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Ar�naire project (LIP, ENS-Lyon)