Re: [ANNOUNCE] Ext3 vs Reiserfs benchmarks

Matthias Andree (matthias.andree@stud.uni-dortmund.de)
Mon, 15 Jul 2002 22:55:05 +0200


On Mon, 15 Jul 2002, Patrick J. LoPresti wrote:

> In a correctly-written application, neither of these things can
> happen. (See my earlier message today on fsync() and MTAs.) To get a
> file onto disk reliably, the application must 1) flush the data, and
> then 2) flush a "validity" indicator. This could be a sequence like:
>
> create temp file
> flush data to temp file
> rename temp file
> flush rename operation
>
> In this sequence, the file's existence under a particular name is the
> indicator of its validity.

Assume that most applications are broken then.

I assume that most will just call close() or fclose() and exit() right
away. Does fclose() imply fsync()?

Some applications will not even check the [f]close() return value...

> It is possible to make an application which relies on data=ordered
> semantics; for example, skipping the "flush data to temp file" step
> above. But such an application would be broken for every version of
> Unix *except* Linux in data=ordered mode. I would call that an
> incorrect application.

Or very specific, at least.

> > Nope, battery backed caches don't make data=writeback more or less safe
> > (with respect to the data anyway). They do make data=ordered and
> > data=journal more safe.
>
> A theorist would say that "more safe" is a sloppy concept. Either an
> operation is safe or it is not. As I said in my last message,
> data=ordered (and data=journal) can reduce the risk for poorly written
> apps. But they cannot eliminate that risk, and for a correctly
> written app, data=writeback is 100% as safe.

IF that application uses a marker to mark completion. If it does not,
data=ordered will be the safe bet, regardless of fsync() or not. The
machine can crash BEFORE the fsync() is called.

-- 
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/