[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Support for filesystem snapshots (?)

From: Vincent Lefevre <vincent-svn_at_vinc17.net>
Date: Tue, 3 Aug 2010 14:25:37 +0200

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)
Received on 2010-08-03 14:26:18 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.