All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bernd Schubert <bschubert@ddn.com>
To: Ted Ts'o <tytso@mit.edu>
Cc: Bernd Schubert <bs_lists@aakef.fastmail.fm>,
	Amir Goldstein <amir73il@gmail.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: ext4_clear_journal_err: Filesystem error recorded from previous mount: IO failure
Date: Sun, 24 Oct 2010 16:42:25 +0200	[thread overview]
Message-ID: <4CC445D1.10908@ddn.com> (raw)
In-Reply-To: <20101024010859.GE24650@thunk.org>

[-- Attachment #1: Type: text/plain, Size: 2385 bytes --]

On 10/24/2010 03:08 AM, Ted Ts'o wrote:
> On Sun, Oct 24, 2010 at 02:20:45AM +0200, Bernd Schubert wrote:
>> Hmm, maybe we have a mis-understanding here. If we could make e2fsck
>> to *only* recovery the journal, that would be perfect. Kernel and
>> e2fsck journal recovery should take approximately the same time. But
>> that option does not exist yet (well, a half baken patch is on my
>> disk now). If e2fsck then would detect as the kernel:
>> "clear_journal_err: Filesystem error recorded from previous mount"
>> and mark the filesystem with an error, that would be all we need to
>> then abort the mount in the pacemaker script and allow us to run a
>> real e2fsck outside of pacemaker.
> 
> What probably makes sense is to have an extended option which causes
> e2fsck to just run the journal and then exit.  Part of running the
> journal should be setting the EXT4_ERROR_FS bit in s_mount_state and
> then clearning the journal.  That seems to be missing entirely from
> e2fsck, which is a bug that we should fix regardless.

Adding the journal option is simple, I will provide a patch by Wednesday
or Thursday. Will also check if it sets EXT2_ERROR_FS and if not, will
try to find some time to add that.

> 
> As far as detecting whether or not the file system has known errors,
> you can do that by using dumpe2fs -h and grepping for "Filesystem
> state".  That can have the values "clean" or "with errors".  (For ext2
> file systems, or ext4 file systems without a journal, you can also
> have the state "not clean" and "not clean with errors", but if you
> have a journal the latter two states shouldn't ever come up.)

I added exactly that to our lustre_server pacemaker agent last week :)
And when I noticed it still mounts filesystems with errors, I started
this thread here.


> 
> That way the logic that you want is something you can build into your
> script, and we don't need to embed application specific logic into
> e2fsprogs.  The ability to just run the journal without doing any
> further checking seems like a reasonable thing to add to e2fsck ---
> and by using dumpe2fs -h you'll be able to detect all possible file
> system errors (not just the ones which are reported via the journal
> error system).
> 
> Does that sound reasonable to you?

Yes, we perfectly agree on each other now :)

Thanks,
Bernd


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]

  reply	other threads:[~2010-10-24 14:42 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-22 13:33 ext4_clear_journal_err: Filesystem error recorded from previous mount: IO failure Bernd Schubert
2010-10-22 17:25 ` Ted Ts'o
2010-10-22 17:42   ` Bernd Schubert
2010-10-22 18:32     ` Ted Ts'o
2010-10-22 18:54       ` Bernd Schubert
2010-10-23 16:00   ` Amir Goldstein
2010-10-23 17:46     ` Bernd Schubert
2010-10-23 22:26       ` Ted Ts'o
2010-10-23 23:56         ` Bernd Schubert
2010-10-24  0:20           ` Bernd Schubert
2010-10-24  1:08             ` Ted Ts'o
2010-10-24 14:42               ` Bernd Schubert [this message]
2010-10-23 22:17     ` Ted Ts'o
2010-10-24  8:50       ` Amir Goldstein
2010-10-24 13:55       ` Ric Wheeler
2010-10-24 14:30         ` Bernd Schubert
2010-10-24 15:20           ` Ric Wheeler
2010-10-24 15:39             ` Bernd Schubert
2010-10-24 15:49               ` Ric Wheeler
2010-10-24 16:16                 ` Bernd Schubert
2010-10-24 16:43                   ` Ric Wheeler
2010-10-25 10:14                     ` Andreas Dilger
2010-10-25 11:45                       ` Ric Wheeler
2010-10-25 12:54                         ` Ric Wheeler
2010-10-25 14:57                           ` Andreas Dilger
2010-10-25 19:49                             ` Ric Wheeler
2010-10-25 20:08                               ` Bernd Schubert
2010-10-25 20:10                                 ` Ric Wheeler
2010-10-25 19:43                       ` Eric Sandeen
2010-10-25 20:37                         ` Bernd Schubert

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=4CC445D1.10908@ddn.com \
    --to=bschubert@ddn.com \
    --cc=amir73il@gmail.com \
    --cc=bs_lists@aakef.fastmail.fm \
    --cc=linux-ext4@vger.kernel.org \
    --cc=tytso@mit.edu \
    /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.