 |
 |
Hi Andy, This is great, thanks! :) Cheers, Matevz On 10/10/11 11:10, Andrew Hanushevsky wrote: > OK, so here is what I am planning on doing for readv > > 1) If you monitor IO then each readv request will have a special readv entry (as > opposed to a standard read entry) that will include: > a) Number of readv segments, > b) number of bytes read, > c) the dictid of the file being read, and > d) the readv distinguisher used to group a single readv request > that produces multiple entries because it reads from multiple files > in the vector together (i.e., you know its from the same readv). > Note that no offset is supplied. If that is needed then.... > > 2) If you monitor IOV then, additionally, the actual vector is unrolled and you > get a read entry for each readv entry. The format is the same as a regular read. > However, you can tell it's a readv because a readv entry will precede it (and > tell you how many read entries will follow). Read entries contain offsets. > > Will satisfy all the requirements? > > Andy > > On Sun, 9 Oct 2011, Matevz Tadel wrote: > >> Hi Andy, >> >> On 10/08/11 11:21, Andrew Hanushevsky wrote: >>> >>> On Sat, 8 Oct 2011, Brian Bockelman wrote: >>> >>>> >>>> On Oct 7, 2011, at 3:37 PM, Andrew Hanushevsky wrote: >>>>> 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? >>> To example uses but it was put in with anticipation of some very clever person >>> capitalizing on this feature. >>> >>>> 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). >>> That information can be put in the summary record, if need be. I say need be >>> because it's a relatively rare event (yes, it does happen in spurts). >> >> Sorry ... what summary record? When a client program crashes, all I get in >> monitoring stream is session disconnect trace. Then I loop over all files >> associated with this session and "close" them manually. >> >> There could be a separate "close on disconnect" trace type that is sent in >> this case and includes all the information usually associated with 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? >>> True, there is no other way of capturing this information. Another case where >>> some more client input would make things more effecient. >> >> What do you mean? The the client would also send monitoring information, >> either directly to the monitoring host or via the server? >> >>>> 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. >>> OK, I will take this into consideration when comming up with a fix. >> >> I'd still vote for a single trace entry for a whole vector read. And then have >> a new option for full vector read unroll as it really pushes monitoring >> overhead to a new level. Now even I have enough ;) >> >> Cheers, >> Matevz >>