 |
 |
On 10/10/11 11:13, Brian Bockelman wrote: > > On Oct 10, 2011, at 1:10 PM, 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…. >> > > This is fine up to here. > >> 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. >> > > I forget - is there an ordering of the monitoring packets? I would expect a non-trivial chance that UDP packets will get reordered. The UDP packets get a sequence id so they can be reordered at the monitoring client. I added a check for that about a week ago and it has not happened since then. But it's also true I set monitoring packet size so that it fits into a single ethernet frame which should further reduce this probability. Matevz <snip>