I'll preface this by saying "when you lose power you lose data"
but in the new scenario, you're more likely to "get your old file back."
In the new async transaction scenario, if you quickly
edit->write->quit->save->lose power
then _nothing_ makes it out to disk - not data, not metadata, nothing.
So, essentially, your old file is still there when you reboot.
In the synchronous transaction case, the write would force the metadata
(including a truncate) out to disk, but the new data never made it. So
you had a file with a size, but no data - hence nulls.
-Eric
On Wed, 6 Mar 2002, D. Stimits wrote:
> I would assume that a file subject to NULLs would still be at risk of
> being emptied out, rather than acting as nice as full journalling would.
> So is this 2.4.18 code intended to simply avoid filling with nulls, or
> does it completely protect the file (the former seems more likely)? It
> does not seem possible to have the advantages of full journalling within
> a meta journalling system.
|