Re: Merging relayfs?

[Tom Zanussi]

=?ISO-8859-2?Q?Tomasz_K=B3oczko?= writes:
 > On Tue, 12 Jul 2005, Tom Zanussi wrote:
[...]
 > >
 > > Most of the time the data is just being buffered and only when the
 > > buffer is full is it written to disk, as one write.  If that's too
 > > disruptive, then maybe you do need to do some aggregation in the kernel,
 > > but it sounds like a special case.
 > 
 > OK .. "so you can say better is stop flushing buffers on measure which 
 > wil take day or more" ? :_)
 > Some DTrace probes/technik are specialy prepared for long or evel very 
 > long time experiment wich will only prodyce few lines results on end of 
 > experiment.
 > Look at DTrace documentation for speculative tracing:
 > http://docs.sun.com/app/docs/doc/817-6223/6mlkidli7?a=view
 > 

It's also possible to do long-running 'experiments' using relayfs, and
never write anything at all to disk.  Here's an example prototype I
did using a Perl interpreter embedded in the user space event-reading
loop:

http://www.listserv.shafik.org/pipermail/ltt-dev/2004-August/000649.html

 > Some experiments do not have deterinistic time and must be finished after 
 > i. e. "occasional failing". What if it will take so long so you will fill 
 > all avalaible storage in relayfs way ?
 > OK, never mind .. you have discontinued storage. Using kind speculative 
 > tracing way I'll have result *just after* "occasional failing" and you 
 > will start parse data stored using relayfs.

As in the example above, you don't necessary need to fill any
available storage.  You can also use relayfs in 'circular-buffer'
mode, which would capture a buffer full of events up the point of your
failure.  Sounds like speculative tracing to me.

Tom


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/