linux-ext4 - Re: ext4 corruption

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] [day] [month] [year] [list]

Date:	Mon, 06 Jun 2011 13:11:32 -0400
From:	micah anderson <micah@...eup.net>
To:	Ted Ts'o <tytso@....edu>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: ext4 corruption

On Mon, 6 Jun 2011 00:19:50 -0400, Ted Ts'o <tytso@....edu> wrote:
> On Sun, Jun 05, 2011 at 11:59:34PM -0400, Micah Anderson wrote:
> > 
> > I previously wrote about a recent conversion from ext3 to ext4 (on
> > Debian Squeeze), which went well. However, I seem to be having problems
> > with the ext4 filesystem.
> 
> Are you using the 2.6.32 kernel (the Debian squeeze default)?  Try

Yes, we are using 2.6.32-34squeeze1.

> updating to 2.6.39.1, and see if that stablizes things.  There have
> been a huge number of bug fixes since 2.6.32, and no one has been
> really backporting patches to such an ancient kernel.  This is one of
> the ways in which Debian Obsolete^H^H^H^H^H^H^H^H Stable can be
> somewhat of a disadvantage.  Unlike the RHEL kernels, no one is
> backporting ext4 bugfixes to older Debian stable kernels, and ext4 was
> still getting a lot of bug fixes in the 2.6.32 days.

Well, it does seem like 2.6.32.y contains quite a number of ext4 fixes:

$ git rev-list v2.6.32..v2.6.32.41 fs/ext4 | wc -l
92

Not an insignificant amount, although it seems the latest was in
2.6.32.23 which was some time ago.

I'm sure that the debian-kernel team would welcome some help with this,
even if it is just some help determining the most important issues to
resolve. 

I would guess that RHEL is in a better position to integrate more
invasive fixes.

> That being said, you're seeing some pretty severe inode *and* block
> allocation bitmap problems, and that doesn't sound like anything I
> remember even back in the 2.6.32 days.  It does make me wonder about
> the stability of the hardware and of the software raid code...

Yeah, so once we've done some destructive badblocks tests on the drives,
we should be able to rule out drive issues at least.

micah

Content of type "application/pgp-signature" skipped