Re: [PATCH] ftrace: add an fsync tracer

[Arjan van de Ven <arjan@infradead.org>]

On Thu, 06 Nov 2008 15:19:01 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> > a syscall tracer will exactly not tell you which file(name) was
> > being fsync()'d which was the whole point.
> 
> It will tell you the process and the fd, and when you have those two
> its a simple step to find the actual file.

actually process+fd is absolutely useless; the typical useage is

fd = open(file)
write(fd, <> )
fsync(fd);
close(fd);

by the time userland gets the data the fd is closed. And heck, even the
program may have exited.
Really, the fd number is only useful for the program itself, not for
any outside part, and especially, later in time.

> 
> > LatencyTOP already KNOWS that fsync is the problem. What it doesn't
> > know is which file is being fsync()d.
> > 
> > fsync is a problem when used incorrectly, not just for ext3 but also
> > due to barriers. That's why it's important to be able to find who
> > calls it when it impacts interactive performance.
> 
> Which suggests you want a tracer that gives more information about who
> generates barriers, not specifically fsync().

that would be a fine second tracer. because the filesystem part of it
is also expensive, and you can diss ext3 all you want, it is reality
for 99% of the people...

(and I suspect that at the barrier level it'll be really hard to get to
a filename)


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org