linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: 丁定华 <dingdinghua85@gmail.com>
To: linux-ext4@vger.kernel.org
Cc: Jan Kara <jack@suse.cz>
Subject: Should we discard jbddirty bit if BH_Freed is set?
Date: Wed, 27 Jan 2010 10:39:13 +0800	[thread overview]
Message-ID: <7bb361261001261839w52466ca9t102ae88930baecf5@mail.gmail.com> (raw)

Hi all:
        I'm a little confused about BH_Freed bit. The only place it is
set is journal_unmap_buffer, which is called by
jbd2_journal_invalidatepage when we want to truncate a file. Since
jbd2_journal_invalidatepage is called outside of transaction, We can't
make sure whether the "add to orphan" operation belongs to committing
transaction or not,  so we can't touch the buffer belongs to
committing transaction, instead BH_Freed bit is set to indicate that
this buffer can be discarded in running transaction. But i think we
shouldn't clear BH_JBDdirty in jbd2_journal_commit_transaction, as
following codes does:
                /* A buffer which has been freed while still being
                 * journaled by a previous transaction may end up still
                 * being dirty here, but we want to avoid writing back
                 * that buffer in the future now that the last use has
                 * been committed.  That's not only a performance gain,
                 * it also stops aliasing problems if the buffer is left
                 * behind for writeback and gets reallocated for another
                 * use in a different page. */
                if (buffer_freed(bh)) {
                        clear_buffer_freed(bh);
                        clear_buffer_jbddirty(bh);
                }
Note that, We can't make sure "current running transaction" can
complete commit work. If we clear BH_JBDdirty bit here, this buffer
may be freed here,  the log space of older transaction may be freed
before the "current running transaction" complete commit work, and if
this happends and system crashed at this moment, filesystem will be
inconsistent.

Above is my analysis, please let me know if it's wrong, and if it's a
bug, may be I can send a patch out, thanks.

--
丁定华
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

             reply	other threads:[~2010-01-27  2:39 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-27  2:39 丁定华 [this message]
     [not found] <7bb361261001261832wb4f9ac2u96fdb6460aa45fa2@mail.gmail.com>
2010-01-27 12:23 ` Should we discard jbddirty bit if BH_Freed is set? Jan Kara
2010-01-28  1:23   ` 丁定华
2010-01-28 12:53     ` Jan Kara
2010-01-29  1:43       ` 丁定华
2010-01-30  6:41         ` 丁定华
2010-02-02 22:02           ` Jan Kara

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=7bb361261001261839w52466ca9t102ae88930baecf5@mail.gmail.com \
    --to=dingdinghua85@gmail.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).