Re: ext3_ordered_writepage() questions

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Mar 16, 2006 at 10:22:40AM -0800, Badari Pulavarty wrote:
> > However, if what we are doing is overwriting our own data with more an
> > updated, more recent version of the data block, do we guarantee that
> > any ordering semantics apply?  For example, what if we write a data
> > block, and then follow it up with some kind of metadata update (say we
> > touch atime, or add an extended attribute).  Do we guarantee that if
> > the metadata update is committed, that the data block will have made
> > it to disk as well?  
> 
> I don't see how we do this today. Yes. Metadata updates are jounalled,
> but I don't see how current adding buffers through journal_dirty_data
> (bh) call can guarantee that these buffers get added to metadata-update
> transaction ?

Even though there aren't any updates to any metadata blocks that take
place between the journal_start() and journal_stop() calls, if
journal_dirty_data() is called (for example in ordered_writepage),
those buffers will be associated with the currently open transaction,
so they will be guaranteed to be written before the transaction is
allowed to commit.

Remember, journal_start and journal_stop do not delineate a full
ext3/jbd transaction, but rather an operation, where a large number of
operations are bundled together to form a transaction.  When you call
journal_start, and request a certain number of credits (number of
buffers that you maximally intend to dirty), that opens up an
operation.  If the operation turns out not to dirty any metadata
blocks at the time of journal_stop(), all of the credits that were
reserved by jouranl_start() are returned to the currently open
transaction.  However, any data blocks which are marked via
journal_dirty_data() are still going to be associated with the
currently open transaction, and they will still be forced out before
the transaction is allowed to commit.

Does that make sense?

						- Ted
-
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/