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

Re: wc atomic rename safety on non-ext3 file systems

From: Chris Frost <frost_at_cs.ucla.edu>
Date: 2007-03-05 08:03:02 CET

On Mon, Mar 05, 2007 at 06:23:08AM +0000, Malcolm Rowe wrote:
> If you're asking whether, in the normal course of events, a userspace
> program would be in a position to observe the rename but not be able to
> read the data, the answer's no. If you're asking whether a crash at the
> right time could leave you with a file that doesn't contain all the data,
> then the answer's yes, as far as I'm aware.

I should have stated that I was asking about the crash case;
thanks for the confirmation!

> In the FSFS filesystem implementation, we do something similar, but before
> the rename we fsync() the file to ensure the data is flushed to disk,
> and, on Linux, we follow up the rename by fsync-ing the target directory,
> which flushes the metadata to disk. (As far as I'm aware, other operating
> systems don't provide any means to request the metadata be flushed, or
> don't need to).

I have noticed this behavior in looking over FSFS's code, yup.

> FSFS needs this behaviour to guarantee durability, but it only uses it
> at a few critical points. The working copy library doesn't provide the
> same guarantees, and would probably be a lot slower if it tried to.

Right. It is an unfortunate speed and safety trade-off.

Chris Frost  |  <http://www.frostnet.net/chris/>
PGP: <http://www.frostnet.net/chris/about/pgp_key.txt>
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 5 08:03:23 2007

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

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