search for: wr_sect

...istinguish VBD types. Therefore, it is better to remove the prefix "tap_" in sysfs entries of blktap. For example, currently sysfs entries are named as follows. [root@xenmachine1 ~]# ls /sys/devices/xen-backend/vbd-1-51712/statistics/ br_req oo_req rd_req rd_sect wr_req wr_sect [root@xenmachine1 ~]# ls /sys/devices/xen-backend/tap-2-51712/statistics/ tap_oo_req tap_rd_req tap_rd_sect tap_wr_req tap_wr_sect After applying these patches, names of sysfs entries are changed as follows. [root@xenmachine1 ~]# ls /sys/devices/xen-backend/vbd-1-51712/statist...

...1573 8 2 0 2433 6688 109973 88770 0 For the red part, I need to change the size to MB or KB. Just now, I check the xentop code, xentop gets the related information from /sys/devices/vbd-29-51713/statistics/rd_sect or /sys/devices/vbd-29-51713/statistics/wr_sect files. I do not know how to change these number to MB or KB. Does anybody know how to do that? _______________________________________________ Xen-users mailing list Xen-users@lists.xen.org http://lists.xen.org/xen-users

Just moving a chunk of files from one filesysstem on xvba to another on xvdb, and was monitoring with xentop as it was taking longer than expected. The VBD_RD and VBD_WR counters were both clocking-up as expected, as was the VBD_RSECT counter, but the VBD_WSECT counter was stuck on zero, I toggled on the individual VBD device counters and these showed the same (with the RD and WR counters

Just moving a chunk of files from one filesysstem on xvba to another on xvdb, and was monitoring with xentop as it was taking longer than expected. The VBD_RD and VBD_WR counters were both clocking-up as expected, as was the VBD_RSECT counter, but the VBD_WSECT counter was stuck on zero, I toggled on the individual VBD device counters and these showed the same (with the RD and WR counters

Hi, One of our colleagues spotted a problem in xentop. Sometimes the VBD_WSECT value suddenly becomes unreasonably high, and it turned out xentop reads /sys/bus/xen-backend/devices/vbd-(domid)-(devID)/statistics/wr_sect into an unsigned long long. That value is exposed by blkback, and among other stat counters, it''s a signed integer: drivers/block/xen-blkback/common.h struct xen_blkif { ... int st_rd_req; int st_wr_req; int st_oo_req; int st_f_req; int st_ds_req; int st_rd_sect; int...

...back: ring-ref 9, event-channel 10, protocol 1 (x86_64-abi) Unable to handle kernel paging request at ffff880074ec2b68 RIP: [<ffffffff804158eb>] skb_copy_bits+0x114/0x1d3 PGD 11a4067 PUD 13a6067 PMD 154e067 PTE 0 Oops: 0000 [1] SMP last sysfs file: /devices/xen-backend/vbd-1-51712/statistics/wr_sect CPU 2 Modules linked in: bridge netloop netbk blktap blkbk sg bonding ipv6 xfrm_nalgo crypto_api ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp libiscsi2 scsi_transport_iscsi2 scsi_transport_iscsi dm_mirror dm_multipath scsi_dh video hwmon backlight sbs i2c_ec i2c_c...

Hi, I just want to know if somebody use 2.6.31.4 xenified kernel (aka OpenSUSE) in production? We have been testing it on new Nehalem Xeon server for few weeks w/o any problem. But as soon we tried it on production machine - after several production domUs started - hard OS failure. We had to switch back to 2.6.18.8 - xen stock kernel. Peter _______________________________________________

..._pfn+0x139/0x1a0 Dec 29 09:30:47 toddb05 kernel: [78295.342523] PGD 2134067 PUD 2537067 PMD 2657067 PTE 80100000a3f93065 Dec 29 09:30:47 toddb05 kernel: [78295.342531] Oops: 0003 [#1] SMP Dec 29 09:30:47 toddb05 kernel: [78295.342537] last sysfs file: /sys/devices/xen-backend/vbd-2-768/statistics/wr_sect Dec 29 09:30:47 toddb05 kernel: [78295.342541] CPU 0 Dec 29 09:30:47 toddb05 kernel: [78295.342543] Modules linked in: rndis_wlan cfg80211 rfkill rndis_host cdc_ether usbnet snd_seq_dummy tun fuse usbbk gntdev netbk blkbk blkback_pagemap blktap domctl xenbus_be evtchn snd_pcm_oss snd_mixer_oss s...

Dear list, This is the V4 of the trim support for xen-blkfront/blkback, Now we move BLKIF_OP_TRIM to BLKIF_OP_DISCARD, and dropped all "trim" stuffs in the patches, and use "discard" instead. Also we updated the helpers of blkif_x86_{32|64}_request or we will meet problems using a non-native protocol. And this patch has been tested with both SSD and raw file, with SSD we will