 |
 |
Good eye Matevz! That's what jet lag does to you, I realized my mistake when I woke this morning. Indeed, I will check in the change. I'm also sending you a pdf descrbing the format via other channels. Andy On Mon, 10 Oct 2011, Matevz Tadel wrote: > Hi Andy, > > Tried running the latest stuff ... but no monitoring data was coming out for: > xrootd.monitor all auth flush io 30s mbuff 1472 window 5s dest files io info user xrootd.t2.ucsd.edu:9930 > > I figured that IOV check resets the monIO to 0, when IOV is not requested, see attached diff. I'm getting the monitoring data after this change ... but maybe there's more to it. > > 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 > > <snip> > > >