On Oct 7, 2011, at 3:37 PM, Andrew Hanushevsky wrote:
Yeah, that's too much.
What does that mean? You want a single entry? That's not always possible since readv allows you to read from multiple files using a single vector.
Interesting! Is there an example use of this interface?
b) You mention a separate entry for readv. Is this a tag on the entry? A
separate code? We can do this since readv requests were never logged in the
first place so no compatability problems.
Yes, Brian and I think this would be the best option, adding a new trace type
for vector reads, sending total number of bytes and number of chunks sent.
That doesn't allow you to do any kind of analysis on data access patterns. That's the whole idea behind detailed
Well there's a middle-ground use case here: being able to monitor activity for each open connection.
In our experience, without the very detailed I/O monitoring, we:
1) Don't get any monitoring for a client that crashes (disconnects without a close).
2) Don't get monitoring while a client is running. Example: it's been 5 hours since a job has started; is this because it is getting 1 byte / second, or because the job takes 5 hours and 1 minute?
So, we find it extremely useful without doing the data access patterns use case. Either way we get the information - unrolling the vector to include all the data, or getting a summary - we'll be happy.