linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Eric Sandeen <esandeen@redhat.com>
Cc: Somchai Smythe <buraphalinuxserver@gmail.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re:
Date: Sun, 17 Feb 2013 22:59:50 -0500	[thread overview]
Message-ID: <20130218035950.GA10361@thunk.org> (raw)
In-Reply-To: <229CCD67-675F-4FB0-93B2-491DDA6BB7C3@redhat.com>

On Sun, Feb 17, 2013 at 05:42:03PM -0500, Eric Sandeen wrote:
> 
> I haven't looked closely at this, but you could unmount and do
> "e2image -r" of the fs to copy a metadata image.  If e2fsck fails
> the same way on the image, you've saved a reproducer, and you could
> re-make /tmp if you like.

This is good advice; in general this error occurs when there is a
hardware problem, where after we finishing running the journal, the
"needs recovery flag" is cleared, and then we close the file system
(to flush our internal caches, since the on-disk blocks might have
gotten updated from running the journal), and then re-open it.  If the
"needs recovery" flag is still set, then we issue this message.  It
indicates either a severe programming bug in e2fsck and its libraries
(in which case having a reproducible test case is really interesting),
or much more commonly, it means that the disk write to the superblock
to clear the "needs recovery" flag didn't "take", and the disk
returned a data block different from the one which we just wrote, thus
indicating some kind of hardware problem.

>From the e2fsck sources

			if (ctx->flags & E2F_FLAG_RESTARTED) {
				/*
				 * Whoops, we attempted to run the
				 * journal twice.  This should never
				 * happen, unless the hardware or
				 * device driver is being bogus.
				 */
				com_err(ctx->program_name, 0,
					_("unable to set superblock flags on %s\n"), ctx->device_name);
				fatal_error(ctx, 0);
			}

Regards,

						- Ted

  reply	other threads:[~2013-02-18  3:59 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-17 13:21 (unknown), Somchai Smythe
2013-02-17 22:42 ` Eric Sandeen
2013-02-18  3:59   ` Theodore Ts'o [this message]
  -- strict thread matches above, loose matches on Subject: below --
2019-12-19 12:31 liming wu
2019-12-20  1:13 ` Andreas Dilger
2017-11-13 14:55 Re: Amos Kalonzo
2017-05-03  6:23 Re: H.A
2017-02-23 15:09 Qin's Yanjun
2015-10-26  7:30 Davies
2015-08-19 13:01 Re: christain147
     [not found] <CAHxZcryF7pNoENh8vpo-uvcEo5HYA5XgkZFWrLEHM5Hhf5ay+Q@mail.gmail.com>
2015-07-05 16:38 ` Re: t0021
2012-02-15 21:17 Re: Irish Lotto
2008-06-16 13:47 (unknown), Gary Hawco
2008-06-16 21:44 ` Nick Dokos
2008-06-23 15:02   ` Re: Jose R. Santos
2008-06-16 12:49 (unknown), Gary Hawco
2008-06-16 20:55 ` Mingming
2008-06-16 14:25   ` Re: Gary Hawco

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=20130218035950.GA10361@thunk.org \
    --to=tytso@mit.edu \
    --cc=buraphalinuxserver@gmail.com \
    --cc=esandeen@redhat.com \
    --cc=linux-ext4@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).