Re: Should we discard jbddirty bit if BH_Freed is set?

[Jan Kara <jack@suse.cz>]

  Hi,

On Wed 27-01-10 10:32:18, 丁定华 wrote:
>         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, filesystem
> will be inconsistent.
  Let me sketch the situation here:
The file F gets truncated. The inode is added to orphan list in some
transaction T1, only then jbd2_journal_invalidatepage can be called. 
As you wrote above, it can happen that jbd2_journal_invalidatepage on
buffer B runs when some transaction T2 containing B is being committed and
in that case we set BH_Freed.  If T2 != T1 - i.e., T2 is being committed
and T1 is the running transaction, note that we clear the dirty bit only
when T2 is fully committed and we are processing forget list. So buffer has
been properly written to T2 and we just won't write it in the transaction
T1. And that is fine because as soon as transaction T1 finishes commit, we
don't care about what happens with buffers of F because the fact that F is
truncated is recorded and in case of crash we finish truncate during
journal replay. And if we crash before T1 finishes commit, we don't care
about contents of T1 either. If T2 == T1, the above reasoning applies as
well and the situation is even simpler.
 
								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
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