| Message ID | 48EF1A11.9090303@hitachi.com |
|---|---|
| State | Accepted, archived |
| Headers | show |
On Fri, Oct 10, 2008 at 06:02:09PM +0900, Hidehiro Kawai wrote: > Currently, original metadata buffers are dirtied when they are > unfiled whether the journal has aborted or not. Eventually these > buffers will be written-back to the filesystem by pdflush. This > means some metadata buffers are written to the filesystem without > journaling if the journal aborts. So if both journal abort and > system crash happen at the same time, the filesystem would become > inconsistent state. Additionally, replaying journaled metadata > can overwrite the latest metadata on the filesystem partly. > Because, if the journal gets aborted, journaled metadata are > preserved and replayed during the next mount not to lose > uncheckpointed metadata. This would also break the consistency > of the filesystem. > > This patch prevents original metadata buffers from being dirtied > on abort by clearing BH_JBDDirty flag from those buffers. Thus, > no metadata buffers are written to the filesystem without journaling. It's not my place to Ack such patches, but I noticed this bug during Plumbers, and Eric and Andreas pointed me to this patch, which fixes it quite nicely. Just $0.02 :-) Joel
On Mon, Oct 13, 2008 at 01:36:42PM -0700, Joel Becker wrote: > > This patch prevents original metadata buffers from being dirtied > > on abort by clearing BH_JBDDirty flag from those buffers. Thus, > > no metadata buffers are written to the filesystem without journaling. > > It's not my place to Ack such patches, but I noticed this bug > during Plumbers, and Eric and Andreas pointed me to this patch, which > fixes it quite nicely. Just $0.02 :-) Already pushed to Linus, and in mainline. :-) - Ted -- 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
Index: linux-2.6.27-rc9-ex4-1/fs/jbd2/commit.c =================================================================== --- linux-2.6.27-rc9-ex4-1.orig/fs/jbd2/commit.c +++ linux-2.6.27-rc9-ex4-1/fs/jbd2/commit.c @@ -504,9 +504,10 @@ void jbd2_journal_commit_transaction(jou jh = commit_transaction->t_buffers; /* If we're in abort mode, we just un-journal the buffer and - release it for background writing. */ + release it. */ if (is_journal_aborted(journal)) { + clear_buffer_jbddirty(jh2bh(jh)); JBUFFER_TRACE(jh, "journal is aborting: refile"); jbd2_journal_refile_buffer(journal, jh); /* If that was the last one, we need to clean up @@ -884,6 +885,8 @@ restart_loop: if (buffer_jbddirty(bh)) { JBUFFER_TRACE(jh, "add to new checkpointing trans"); __jbd2_journal_insert_checkpoint(jh, commit_transaction); + if (is_journal_aborted(journal)) + clear_buffer_jbddirty(bh); JBUFFER_TRACE(jh, "refile for checkpoint writeback"); __jbd2_journal_refile_buffer(jh); jbd_unlock_bh_state(bh);
Currently, original metadata buffers are dirtied when they are unfiled whether the journal has aborted or not. Eventually these buffers will be written-back to the filesystem by pdflush. This means some metadata buffers are written to the filesystem without journaling if the journal aborts. So if both journal abort and system crash happen at the same time, the filesystem would become inconsistent state. Additionally, replaying journaled metadata can overwrite the latest metadata on the filesystem partly. Because, if the journal gets aborted, journaled metadata are preserved and replayed during the next mount not to lose uncheckpointed metadata. This would also break the consistency of the filesystem. This patch prevents original metadata buffers from being dirtied on abort by clearing BH_JBDDirty flag from those buffers. Thus, no metadata buffers are written to the filesystem without journaling. Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com> --- fs/jbd2/commit.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) -- 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