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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
