On Tue, Aug 21, 2007 at 09:02:45AM +0100, Richard W.M. Jones wrote: > Daniel P. Berrange wrote: > >On Mon, Aug 20, 2007 at 04:31:26PM +0100, Richard W.M. Jones wrote: > >>This patch adds block device and network stats. The main changes over > >>the previous version are: > >> > >>* Remote support. > >>* Change Xen network interface names to have the form "vif<domid>.<n>"[1]. > >> > >>Discussions about the previous version may be found starting here: > >>https://www.redhat.com/archives/libvir-list/2007-August/thread.html#00064 > >> > >>I have left use of stdint.h / int64_t, since it wasn't clear to me what > >>conclusion people had arrived at. > > > >Personally I'm for using long long, since its consistent with the other > >existing APIs using 64 bit quantities. They're both standards so there's > >no much of a reason to favour one over the other. > > I favour int64_t, because I want 64 bit integers (signed in this case > because I want the special -1 value). C doesn't specify a maximum width > for "long long". > > >I notice the Xen impl of the block stats only fills in the rd_req and > >wr_req > >fields, not the rd_bytes and wr_bytes fields. Are requests always fixed at > >512 bytes in size ? If so, should be just junk those fields and only return > >data in terms of the bytes (other units can be calculated as needed). As a > >point of reference libstatgrab only returns bytes read/written for disks. > > I assumed that Xen requests were variable in size ... That is based on > my reading of this code from blkif.h: Ok, yes I they are variable size. I was mixing up requests vs sectors, the latter being fixed, the former being variable since they can be made up of multiple sectors. > If it is true that requests have a fixed size, then returning bytes > _also_ would be good, but I suspect that we should also still return > requests as well since (a) it costs virtually nothing to do so, and (b) > it might be interesting to find the average size of each request, since > lots of small requests are likely to be less efficient than small > numbers of large requests. Yes, we need both. If we can't find actual request sizes for Xen, we should make a note and see if its possible add this to future Xen kernel backend drivers. > >For hdNNN based disks it seems to be > > > > ide major number corresponding to disk letter * 256 + minor number > > as calculated from partition numbers. > > OK ... I've never seen Xen guests with sdX/hdX devices. Are they common? Any HVM guest.... A lot of people do use them in paravirt too, we refuse to use it in Fedora because the ability to hijack hdN and sdN was disappearing in paravirt_ops Xen merge. So hopefully not so common in future, but we'll likely hit them periodically in the wild Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list