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

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