[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: ordered vs full journaling mode



Hi,

On Fri, 2003-10-10 at 17:17, Vijayan Prabhakaran wrote:

> In ordered data journaling mode, if the system crashes after writing
> the blocks of B but before updating the metadata of A (that is,
> between steps 4 and 5), then A might see spurious data. However this
> problem cannot happen if we have a full journaling mode.
> 
> Is the above example correct ? 

No. As long as the delete of file A has not been committed to disk, we
won't allow file B to use the same data blocks, precisely to avoid this
scenario.  That's what the "b_committed_data" field of the journal_head
is there for --- it is only used for bitmap blocks, and is there
precisely so that we can spot disk blocks which have been freed but
where the freeing transaction has not yet committed.

> If not, could you please give me a
> situation where ordered data journaling mode will not give as much
> reliability as the full journaling mode ?

I don't know of any.  Journaled data mode was provided as a performance
option; it's slower for most things but can be faster than ordered mode
for some heavily synchronous workloads involving a lot of data and
metadata updates.  But ordered mode was never expected to be any less
correct than journaled-data mode.

Only the writeback mode offers any less-strong data integrity
guarantees, and even in that mode we don't allow freed blocks to be
overwritten until commit --- if we undo a delete of an existing file on
disk, it always comes back fully intact.  Only writes of _new_ files may
be incomplete after a crash in writeback mode, because in that mode we
don't flush the data blocks for newly-allocated files to disk before
committing the inodes and indirect blocks.

Cheers,
 Stephen




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]