[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20101029145212.GA21205@thunk.org>
Date: Fri, 29 Oct 2010 10:52:12 -0400
From: Ted Ts'o <tytso@....edu>
To: Pekka Enberg <penberg@...nel.org>
Cc: Chris Mason <chris.mason@...cle.com>, Ingo Molnar <mingo@...e.hu>,
Aidar Kultayev <the.aidar@...il.com>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Jens Axboe <axboe@...nel.dk>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Nick Piggin <npiggin@...e.de>,
Arjan van de Ven <arjan@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: 2.6.36 io bring the system to its knees
On Thu, Oct 28, 2010 at 08:57:49PM +0300, Pekka Enberg wrote:
> Don't we need to call ext4_should_writeback_data() before we drop the
> lock? It pokes at ->i_mode which needs ->i_mutex AFAICT.
No, it should be fine. It's not like a file is going to change from
being a regular file to a directory or vice versa. :-)
>From a quick inspection it looks OK, but I haven't had the time to
look more closely to be 100% sure, and of course I haven't run it
through a battery of regression tests. For normal usage it should be
fine though.
Aidar, if you'd be willing to try it with this patch applied, and with
the file system mounted data=writeback, and then let me know what the
latencytop reports, that would be useful. I'm fairly sure that fixing
llseek() probably won't make that much difference, since it will
probably spread things out to other places, but it would be good to
make the experiment.
We will probably also need to use the uninitialized bit for protecting
data from showing up after a crash for extent-based files, and turning
on data=writeback is a good way to simulate that. (Sorry, no way
we're going to make a change like that this merge cycle, but that
might be something we could do for 2.6.38.) But I am curious to see
what are the next things that come up as being problematic after that.
Thanks,
- Ted
--
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