[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101110145712.GB22073@infradead.org>
Date: Wed, 10 Nov 2010 09:57:12 -0500
From: Christoph Hellwig <hch@...radead.org>
To: Theodore Tso <tytso@....EDU>
Cc: Dave Chinner <david@...morbit.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jens Axboe <axboe@...nel.dk>, dave b <db.pub.mail@...il.com>,
Sanjoy Mahajan <sanjoy@...n.edu>,
Jesper Juhl <jj@...osbits.net>,
Chris Mason <chris.mason@...cle.com>,
Ingo Molnar <mingo@...e.hu>, Pekka Enberg <penberg@...nel.org>,
Aidar Kultayev <the.aidar@...il.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Nick Piggin <npiggin@...e.de>,
Arjan van de Ven <arjan@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Corrado Zoccolo <czoccolo@...il.com>,
Shaohua Li <shaohua.li@...el.com>,
Steven Barrett <damentz@...il.com>
Subject: Re: 2.6.36 io bring the system to its knees
On Wed, Nov 10, 2010 at 09:33:29AM -0500, Theodore Tso wrote:
> The chance that this occurs using data=writeback in ext4 is much less, BTW, because with delayed allocation we delay updating the inode until right before we write the block. I have a plan for changing things so that we write the data blocks *first* and then update the metadata blocks second, which will mean that ext4 data=ordered will go away entirely, and we'll get both the safety and as well as avoiding the forced data page writeouts during journal commits.
That's the scheme used by XFS and btrfs in one form or another. Chris
also had a patch to implement it for ext3, which unfortunately fell
under the floor.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists