 |
 |
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. Brian