All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
To: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	sct@redhat.com, adilger@clusterfs.com,
	linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org,
	Josef Bacik <jbacik@redhat.com>, Mingming Cao <cmm@us.ibm.com>,
	Satoshi OSHIMA <satoshi.oshima.fk@hitachi.com>,
	sugita <yumiko.sugita.yf@hitachi.com>
Subject: Re: [PATCH 3/4] jbd: abort when failed to log metadata buffers	(rebased)
Date: Wed, 21 May 2008 10:33:17 +0900	[thread overview]
Message-ID: <48337BDD.60705@hitachi.com> (raw)
In-Reply-To: <20080519031431.GC10233@duck.suse.cz>

Hi,

Jan Kara wrote:
> 
> On Fri 16-05-08 19:26:57, Hidehiro Kawai wrote:
> 
>>Jan Kara wrote:
>>
>>
>>>On Wed 14-05-08 13:49:51, Hidehiro Kawai wrote:
>>>
>>>
>>>>Subject: [PATCH 3/4] jbd: abort when failed to log metadata buffers
>>>>
>>>>If we failed to write metadata buffers to the journal space and
>>>>succeeded to write the commit record, stale data can be written
>>>>back to the filesystem as metadata in the recovery phase.
>>>>
>>>>To avoid this, when we failed to write out metadata buffers,
>>>>abort the journal before writing the commit record.
>>>>
>>>>Signed-off-by: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
>>>>---
>>>>fs/jbd/commit.c |    3 +++
>>>>1 file changed, 3 insertions(+)
>>>>
>>>>Index: linux-2.6.26-rc2/fs/jbd/commit.c
>>>>===================================================================
>>>>--- linux-2.6.26-rc2.orig/fs/jbd/commit.c
>>>>+++ linux-2.6.26-rc2/fs/jbd/commit.c
>>>>@@ -703,6 +703,9 @@ wait_for_iobuf:
>>>>		__brelse(bh);
>>>>	}
>>>>
>>>>+	if (err)
>>>>+		journal_abort(journal, err);
>>>>+
>>>>	J_ASSERT (commit_transaction->t_shadow_list == NULL);
>>>
>>>  Shouldn't this rather be further just before
>>>journal_write_commit_record()? We should abort also if writing revoke
>>>records etc. failed, shouldn't we?
>>
>>Unlike metadata blocks, each revoke block has a descriptor with the
>>sequence number of the commiting transaction.  If we failed to write
>>a revoke block, there should be an old control block, metadata block,
>>or zero-filled block where we tried to write the revoke block.
>>In the recovery process, this old invalid block is detected by
>>checking its magic number and sequence number, then the transaction
>>is ignored even if we have succeeded to write the commit record.
>>So I think we don't need to check for errors just after writing
>>revoke records.
> 
>   Yes, I agree that not doing such check will not cause data corruption but
> still I think that in case we fail to properly commit a transaction, we
> should detect the error and abort the journal...

I see.  I'll move the aborting point to just before
journal_write_commit_record() in the next version.

Thanks,
-- 
Hidehiro Kawai
Hitachi, Systems Development Laboratory
Linux Technology Center


  reply	other threads:[~2008-05-21  1:33 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-14  4:43 [PATCH 0/4] jbd: possible filesystem corruption fixes (rebased) Hidehiro Kawai
2008-05-14  4:47 ` [PATCH 1/4] jbd: strictly check for write errors on data buffers (rebased) Hidehiro Kawai
2008-05-14 12:56   ` Jan Kara
2008-05-14  4:48 ` [PATCH 2/4] jbd: ordered data integrity fix (rebased) Hidehiro Kawai
2008-05-14 13:10   ` Jan Kara
2008-05-16 10:25     ` Hidehiro Kawai
2008-05-19  3:11       ` Jan Kara
2008-05-14  4:49 ` [PATCH 3/4] jbd: abort when failed to log metadata buffers (rebased) Hidehiro Kawai
2008-05-14 13:15   ` Jan Kara
2008-05-16 10:26     ` Hidehiro Kawai
2008-05-19  3:14       ` Jan Kara
2008-05-21  1:33         ` Hidehiro Kawai [this message]
2008-05-14  4:50 ` [PATCH 4/4] jbd: fix error handling for checkpoint io (rebased) Hidehiro Kawai
2008-05-14 13:16   ` Josef Bacik
2008-05-14 14:44     ` Jan Kara
2008-05-14 14:37       ` Josef Bacik
2008-05-16 10:28         ` Hidehiro Kawai
2008-05-14 14:32   ` Jan Kara
2008-05-16 10:29     ` Hidehiro Kawai
2008-05-19  3:38       ` Jan Kara
2008-05-21  1:34         ` Hidehiro Kawai
2008-05-23 22:28           ` Jan Kara
2008-05-26  4:57             ` Hidehiro Kawai

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=48337BDD.60705@hitachi.com \
    --to=hidehiro.kawai.ez@hitachi.com \
    --cc=adilger@clusterfs.com \
    --cc=akpm@linux-foundation.org \
    --cc=cmm@us.ibm.com \
    --cc=jack@suse.cz \
    --cc=jbacik@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=satoshi.oshima.fk@hitachi.com \
    --cc=sct@redhat.com \
    --cc=yumiko.sugita.yf@hitachi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.