public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Andrew Morton <akpm@osdl.org>,
	sct@redhat.com, lkml <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	jack@suse.cz
Subject: Re: ext3_ordered_writepage() questions
Date: Thu, 16 Mar 2006 16:04:24 -0500	[thread overview]
Message-ID: <20060316210424.GD29275@thunk.org> (raw)
In-Reply-To: <1142533360.21442.153.camel@dyn9047017100.beaverton.ibm.com>

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

  reply	other threads:[~2006-03-16 21:04 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-08  0:19 [RFC PATCH 0/3] VFS changes to collapse all the vectored and AIO support Badari Pulavarty
2006-03-08  0:22 ` [PATCH 1/3] Vectorize aio_read/aio_write methods Badari Pulavarty
2006-03-08 12:44   ` christoph
2006-03-08  0:23 ` [PATCH 2/3] Remove readv/writev methods and use aio_read/aio_write instead Badari Pulavarty
2006-03-08 12:45   ` christoph
2006-03-08 16:26     ` Badari Pulavarty
2006-03-08  0:24 ` [PATCH 3/3] Zach's core aio changes to support vectored AIO Badari Pulavarty
2006-03-08  3:37   ` Benjamin LaHaise
2006-03-08 16:34     ` Badari Pulavarty
2006-03-08 12:47 ` [RFC PATCH 0/3] VFS changes to collapse all the vectored and AIO support christoph
2006-03-08 16:24   ` Badari Pulavarty
2006-03-09 16:17   ` ext3_ordered_writepage() questions Badari Pulavarty
2006-03-09 23:35     ` Andrew Morton
2006-03-10  0:36       ` Badari Pulavarty
2006-03-16 18:09         ` Theodore Ts'o
2006-03-16 18:22           ` Badari Pulavarty
2006-03-16 21:04             ` Theodore Ts'o [this message]
2006-03-16 21:57               ` Badari Pulavarty
2006-03-16 22:05                 ` Jan Kara
2006-03-16 23:45                   ` Badari Pulavarty
2006-03-17  0:44                     ` Theodore Ts'o
2006-03-17  0:54                     ` Andreas Dilger
2006-03-17 17:05                       ` Stephen C. Tweedie
2006-03-17 21:32                         ` Badari Pulavarty
2006-03-17 22:22                           ` Stephen C. Tweedie
2006-03-17 22:38                             ` Badari Pulavarty
2006-03-17 23:23                               ` Mingming Cao
2006-03-20 17:05                                 ` Stephen C. Tweedie
2006-03-18  2:57                             ` Suparna Bhattacharya
2006-03-18  3:02                           ` Suparna Bhattacharya
2006-03-17 15:32           ` Jamie Lokier
2006-03-17 21:50             ` Stephen C. Tweedie
2006-03-17 22:11               ` Theodore Ts'o
2006-03-17 22:44                 ` Jamie Lokier
2006-03-18 23:40                   ` Theodore Ts'o
2006-03-19  2:36                     ` Jamie Lokier
2006-03-19  5:28                       ` Chris Adams
2006-03-20  2:18                       ` Theodore Ts'o
2006-03-20 16:26                       ` Stephen C. Tweedie
2006-03-17 22:23               ` Jamie Lokier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060316210424.GD29275@thunk.org \
    --to=tytso@mit.edu \
    --cc=akpm@osdl.org \
    --cc=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbadari@us.ibm.com \
    --cc=sct@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox