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/
This archive was generated by hypermail 2b29 : Mon Jul 15 2002 - 22:00:31 EST