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

Message-ID: <20110228225559.GK28617@thunk.org>
Date:	Mon, 28 Feb 2011 17:55:59 -0500
From:	Ted Ts'o <tytso@....edu>
To:	"Bill Huey (hui)" <bill.huey@...il.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: ext4 corruption

On Mon, Feb 28, 2011 at 12:18:16PM -0800, Bill Huey (hui) wrote:
> What ever is in the latest Ubuntu maverick, 2.6.35 for the kernel.
> 
> The only thing that makes it not looking like it was a storage problem
> is this line that comes before the SATA error:
> 
> -----
> Feb 25 04:41:26 finfin kernel: [206290.181230] JBD: Spotted dirty
> metadata buffer (dev = sdb1, blocknr = 0). There's a risk of
> filesystem corruption in case of system crash.
> -----

There are a few places where we update the superblock bypassing the
journal layer.  (For example, when we set the RO_COMPAT_LARGE_FILE
feature flag if it wasn't previously set).  Those should be cleaned
up, but it's not related to the rest of the scary-looking corruption
which you saw.  The worst that might happen is specific superblock
update might get lost (i.e., the RO_COMPAT_LARGE_FILE feature flag) on
a crash before we commit some other superblock change to the journal.

  	       	  	      	    	       - 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