linux-ext4 - Re: ext4: journal has aborted

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20140703144646.GD5216@thunk.org>
Date:	Thu, 3 Jul 2014 10:46:46 -0400
From:	Theodore Ts'o <tytso@....edu>
To:	David Jander <david@...tonic.nl>
Cc:	Matteo Croce <technoboy85@...il.com>,
	"Darrick J. Wong" <darrick.wong@...cle.com>,
	linux-ext4@...r.kernel.org
Subject: Re: ext4: journal has aborted

On Thu, Jul 03, 2014 at 04:15:51PM +0200, David Jander wrote:
> 
> Could (a) be caused by a bug in the mmc subsystem or in the MMC peripheral
> driver? Can you explain why I don't see any problems with EXT3?

It's possible.  I seem to recall a bug related to the mmc subsystem
that was causing file system corruption after power failure across
multiple file systems --- xfs, and reiserfs were mentioned, as I
recall.  I *thought* the problem was fixed, and then backported if
necessary.  Hmm...  Here's where that bug was reported:

	https://lkml.org/lkml/2014/6/12/19

... but I havne't found the fix yet.

Now, this would be quite different from the bug Matteo was seeing,
since he has a Samsung SSD which is *not* a MMC device.

As far as why you aren't seeing a problem with ext3, it doesn't have
the same sort of paranoid checks that ext4 has, so it's less likely to
catch certain problems at runtime.  If you ran fsck on an ext3 file
system, and it was corrupt, of course that that would show th
eproblem.

> I left the system running (it started from a dirty EXT4 partition), and I am
> seen the following error pop up after a few minutes. The system is not doing
> much (some syslog activity maybe, but not much more):
> 
> [  303.072983] EXT4-fs (mmcblk1p2): error count: 4
> [  303.077558] EXT4-fs (mmcblk1p2): initial error at 1404216838: ext4_mb_generate_buddy:756
> [  303.085690] EXT4-fs (mmcblk1p2): last error at 1404388969: ext4_mb_generate_buddy:757
> 
> What does that mean?

This means that file sysgtem has errors that weren't fixed after an
fsck.  The first error occured at:

% date -d @1404216838
Tue Jul  1 08:13:58 EDT 2014

and the most recent error occured at:

% date -d @1404388969
Thu Jul  3 08:02:49 EDT 2014

The error count information should have gotten cleared by e2fsck, so
long as you are using a version of e2fsck newer than 1.41.13, released
in December 2010.

So if it has not been cleared, and you've since rebooted, that's an
indication that e2fsck isn't getting run at boot.  If you haven't
rebooted yet, then about once a day, you'll see that message in your
syslog.  It's there so that people know that their file system has
been problems, and they *really* should get it unmounted and checked
before they lose more data....

The reason why I added this is because there were systems where people
weren't noticing that they had been running with a corrupted file
systems for days, weeks, months, etc., and then would complain that
they had lost lots of data.  By putting something in the logs once a
day, hopefully it would reduce the chance of this happening.  (And if
they had configured their file system to panic when an error was
detected, via "tune2fs -e panic /dev/sdXX", so long as their init
scripts were properly configured, the file system should have been
repaired after the reboot.)

					- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html