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
>
