[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1225976138.7803.4485.camel@twins>
Date: Thu, 06 Nov 2008 13:55:38 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Arjan van de Ven <arjan@...radead.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, linux-kernel@...r.kernel.org,
mingo@...e.hu
Subject: Re: [PATCH] ftrace: add an fsync tracer
On Wed, 2008-11-05 at 09:49 -0800, Arjan van de Ven wrote:
> From 63c1b869d94eb31a98015af09fb24e22151f2f00 Mon Sep 17 00:00:00 2001
> From: Arjan van de Ven <arjan@...ux.intel.com>
> Date: Tue, 4 Nov 2008 21:08:11 -0800
> Subject: [PATCH] ftrace: add an fsync tracer
>
> fsync() (and its cousin, fdatasync()) are important chokepoints in the
> kernel as they imply very expensive operations, both in terms of filesystem
> operations (ext3 writes back its entire journal) as well as the block layer
> (fsync() implies sending a cache flushing barrier to the SATA/SCSI disk).
>
> This tracer makes a log of which application calls fsync() on which file,
> so that developers and others interested in finding these choke points
> can locate them and fix them in the apps that call this function.
Sorry, but I have to object to such single purpose tracers..
If we go this way we'll end up with a gazillion little tracers, non of
which are really useful.
Please work on getting something like a syscall tracer, or lttng like
event tracer.
Both of those should be able to find such badness, but are also able to
diagnose many more issues.
Also, sure fsync() is expensive, but you make it sound like its a bad
thing. Lets not teach people to ignore data integrity just because ext3
is such a massive piece of shit.
--
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