[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20081204041016.GA13887@mit.edu>
Date: Wed, 3 Dec 2008 23:10:16 -0500
From: Theodore Tso <tytso@....edu>
To: Greg KH <gregkh@...e.de>
Cc: linux-kernel@...r.kernel.org, stable@...nel.org,
Justin Forbes <jmforbes@...uxtx.org>,
Zwane Mwaikambo <zwane@....linux.org.uk>,
Randy Dunlap <rdunlap@...otime.net>,
Dave Jones <davej@...hat.com>,
Chuck Wolber <chuckw@...ntumlinux.com>,
Chris Wedgwood <reviews@...cw.f00f.org>,
Michael Krufky <mkrufky@...uxtv.org>,
Chuck Ebbert <cebbert@...hat.com>,
Domenico Andreoli <cavokz@...il.com>, Willy Tarreau <w@....eu>,
Rodrigo Rubira Branco <rbranco@...checkpoint.com>,
Jake Edge <jake@....net>, Eugene Teo <eteo@...hat.com>,
torvalds@...ux-foundation.org, akpm@...ux-foundation.org,
alan@...rguk.ukuu.org.uk, Frederic Bohe <frederic.bohe@...l.net>,
Ext4 Developers List <linux-ext4@...r.kernel.org>
Subject: Re: [patch 086/104] ext4: fix initialization of UNINIT bitmap
blocks
On Wed, Dec 03, 2008 at 11:56:18AM -0800, Greg KH wrote:
> 2.6.27-stable review patch. If anyone has any objections, please let us know.
Turns out this patch introduces a worse regression than it fixes. The
bug that the patches fixes is that on-line resizes of filesystems with
a 1k blocksize will usually fail. The regression is that when a
filesystem with 1k blocksize is stressed, the filesystem can get
corrupted. On balance, on-line resizing failing is less of a disaster
than corrupting the filesystem when its stressed. Fortunately, it's
only an issue when the filesystem blocksize is less than the page
size, which isn't the common case at least for the x86.
There are patches queued up to address this, but they haven't hit
mainline yet. Probably best to pull this from the stable tree for
now.
- 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
Powered by blists - more mailing lists