From: Hidehiro Kawai <hidehiro.kawai.ez@hitachi.com>
To: Josef Bacik <jbacik@redhat.com>
Cc: Jan Kara <jack@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
sct@redhat.com, adilger@clusterfs.com,
linux-kernel@vger.kernel.org, linux-ext4@vger.kernel.org,
Mingming Cao <cmm@us.ibm.com>,
Satoshi OSHIMA <satoshi.oshima.fk@hitachi.com>,
sugita <yumiko.sugita.yf@hitachi.com>
Subject: Re: [PATCH 4/4] jbd: fix error handling for checkpoint io (rebased)
Date: Fri, 16 May 2008 19:28:13 +0900 [thread overview]
Message-ID: <482D61BD.2040700@hitachi.com> (raw)
In-Reply-To: <20080514143747.GC20256@unused.rdu.redhat.com>
Hi,
Thank you for review.
Josef Bacik wrote:
> On Wed, May 14, 2008 at 04:44:10PM +0200, Jan Kara wrote:
>
>>>>
>>>>Index: linux-2.6.26-rc2/fs/ext3/super.c
>>>>===================================================================
>>>>--- linux-2.6.26-rc2.orig/fs/ext3/super.c
>>>>+++ linux-2.6.26-rc2/fs/ext3/super.c
>>>>@@ -395,7 +395,10 @@ static void ext3_put_super (struct super
>>>> ext3_xattr_put_super(sb);
>>>> journal_destroy(sbi->s_journal);
>>>> if (!(sb->s_flags & MS_RDONLY)) {
>>>>- EXT3_CLEAR_INCOMPAT_FEATURE(sb, EXT3_FEATURE_INCOMPAT_RECOVER);
>>>>+ if (!is_checkpoint_aborted(sbi->s_journal)) {
>>>>+ EXT3_CLEAR_INCOMPAT_FEATURE(sb,
>>>>+ EXT3_FEATURE_INCOMPAT_RECOVER);
>>>>+ }
>>>> es->s_state = cpu_to_le16(sbi->s_mount_state);
>>>> BUFFER_TRACE(sbi->s_sbh, "marking dirty");
>>>> mark_buffer_dirty(sbi->s_sbh);
>>>
>>>Is this bit here really needed? If we abort the journal the fs will be mounted
>>>read only and we should never get in here. Is there a case where we could abort
>>>the journal and not be flipped to being read-only? If there is such a case I
>>>would think that we should fix that by making the fs read-only, and not have
>>>this check.
>>
>> Actually, journal_abort() (which could be called from journal_destroy())
>>does nothing to the filesystem as such. So at this moment, ext3 can still
>>happily think everything is OK. We only detect aborted journal in
>>ext3_journal_start_sb() and call ext3_abort() in that case, which does all
>>that is needed...
Yes, that is why I added this check.
> Hmm you're right, I was thinking we did some other stuff before put_super which
> would have caught a journal abort but it looks like thats not the case. Still
> shouldn't do is_checkpoint_aborted(sbi->s_journal) since journal_destroy()
> kfree's the journal. Should probably move the is_journal_aborted() check above
> that or something. Thanks,
Good catch, I will fix it.
Thanks!
--
Hidehiro Kawai
Hitachi, Systems Development Laboratory
Linux Technology Center
next prev parent reply other threads:[~2008-05-16 10:28 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
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 [this message]
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=482D61BD.2040700@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.