 |
 |
Hi Matevz, On Fri, 7 Oct 2011, Matevz Tadel wrote: > Hi Andy, > > On 10/07/11 12:22, Andrew Hanushevsky wrote: >> 1) Some modes of sending data are not counted in the file statistics, notably >> when sendfile() is used. > But it should be possible to add it to both counters (global and trace), right? Yes, they should be that's why it's a bug :-) >> a) Does each read segment create a monitor record entry? This could cause >> excessive number of entries as readv vectors can get quite long. On the other >> hand, the alternate read mechanism would simply issue multiple reads and all of >> these would have been put in the monitor record. So, it may be moot. > > 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. >> 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 monitoring. So, this doesn't seem right to me. > Is there such a thing as vector write? No, there is not. >> Once you post this as a bug, I will add his to your post. > > Are we also hit by case 1)? Should I open a new bug for this cases, too? Not really, it's all one inter-related problem. Andy