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]

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

On Tue, Jul 01, 2014 at 10:55:11AM +0200, Matteo Croce wrote:
> 2014-07-01 10:42 GMT+02:00 Darrick J. Wong <darrick.wong@...cle.com>:
> 
> I have a Samsung SSD 840 PRO

Matteo,

For you, you said you were seeing these problems on 3.15.  Was it
*not* happening for you when you used an older kernel?  If so, that
would help us try to provide the basis of trying to do a bisection
search.

Using the kvm-xfstests infrastructure, I've been trying to reproduce
the problem as follows:

./kvm-xfstests  --no-log -c 4k generic/075 ; e2fsck -p /dev/heap/test-4k ; e2fsck -f /dev/heap/test-4k 

xfstests geneeric/075 runs fsx which does a fair amount of block
allocation deallocations, and then after the test finishes, it first
replays the journal (e2fsck -p) and then forces a fsck run on the
test disk that I use for the run.

After I launch this, in a separate window, I do this:

	sleep 60  ; killall qemu-system-x86_64 

This kills the qemu process midway through the fsx test, and then I
see if I can find a problem.  I haven't had a chance to automate this
yet, and it is my intention to try to set this up where I can run this
on a ramdisk or a SSD, so I can more closely approximate what people
are reporting on flash-based media.

So far, I haven't been able to reproduce the problem.  If after doing
a large number of times, it can't be reproduced (especially if it
can't be reproduced on an SSD), then it would lead us to believe that
one of two things is the cause.  (a) The CACHE FLUSH command isn't
properly getting sent to the device in some cases, or (b) there really
is a hardware problem with the flash device in question.

Cheers,

						- 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