Messages in this thread | | | Date | Mon, 15 Jul 2002 22:55:05 +0200 | From | Matthias Andree <> | Subject | Re: [ANNOUNCE] Ext3 vs Reiserfs benchmarks |
| |
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/
| |