similar to: [blkback] blkback statistic counters are signed values

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

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 all, Now I use xentop to get disk statistical information. NAME STATE CPU(sec) CPU(%) MEM(k) MEM(%) MAXMEM(k) MAXMEM(%) VCPUS NETS NETTX(k) NETRX(k) VBDS VBD_OO VBD_RD VBD_WR VBD_RSECT VBD_WSECT SSID Domain-0 -----r 96233 0.7 3902464 23.3 no limit n/a 12 0 0 0 0 0 0 0 0 0 0 slave3

Hi have 4 dom0 with debian lenny running xen. When I run ps axf|grep xvd I see it''s different on diferent dom0s. dom0-A 15677 ? S< 0:00 \_ [blkback.139.xvd] 15678 ? S< 0:38 \_ [blkback.139.xvd] 17015 ? S< 0:00 \_ [blkback.140.xvd] 17016 ? S< 2:34 \_ [blkback.140.xvd] 21309 ? S< 0:00 \_ [blkback.142.xvd] 21310 ?

Hello Roger Pau Monne, The patch 4d4f270f1880: "xen-blkback: move free persistent grants code" from Nov 16, 2012, leads to the following warning: drivers/block/xen-blkback/blkback.c:238 free_persistent_gnts() warn: 'persistent_gnt' was already freed. drivers/block/xen-blkback/blkback.c 232 pages[segs_to_unmap] = persistent_gnt->page; 233

Hello Roger Pau Monne, The patch 4d4f270f1880: "xen-blkback: move free persistent grants code" from Nov 16, 2012, leads to the following warning: drivers/block/xen-blkback/blkback.c:238 free_persistent_gnts() warn: 'persistent_gnt' was already freed. drivers/block/xen-blkback/blkback.c 232 pages[segs_to_unmap] = persistent_gnt->page; 233

Moving grant ref handles from blkbk to pending_req will allow us to get rid of the shared blkbk structure. Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: xen-devel@lists.xen.org --- drivers/block/xen-blkback/blkback.c | 16 ++++------------ 1 files changed, 4 insertions(+), 12 deletions(-) diff --git

Hi Everyone, When you want to use ionice to limit the amount of disk a DomU has, due to have to run ionice on every blkback process? Incidently, what is the format of the blkback process? I see the following in ps aux: blkback.xx.xvda blkback.xx.xvda1 blkback.xx.xvd where xx appears to be the domain ID. I''m curious as to the last few letters mean? Thanks

Hi. These patches add the output function for blktap statistics into xentop. Currently, xentop outputs only blkback statistics, and not blktap statistics. By these patches, xentop is made cover both blkback and blktap. In xen, back-end driver has two types; blkback and blktap. Blkback driver is old back-end driver. Blktap driver is new back-end driver and is recommended currently. Usage of both

...because vbd_size() dereferences bd_disk if bd_part is NULL. Signed-off-by: Laszlo Ersek<lersek@redhat.com> --- drivers/xen/blkback/vbd.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff -r 415a9b435fef drivers/xen/blkback/vbd.c --- a/drivers/xen/blkback/vbd.c Mon May 23 18:36:33 2011 +0100 +++ b/drivers/xen/blkback/vbd.c Wed May 25 12:15:26 2011 +0200 @@ -73,7 +73,6 @@

With the introduction of indirect segments we can receive requests with a number of segments bigger than the maximum number of allowed iovecs in a bios, so make sure that blkback doesn't try to allocate a bios with more iovecs than BIO_MAX_PAGES Signed-off-by: Roger Pau Monné <roger.pau@citrix.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> ---

Hi,all In the vbd blkback driver(linux/drivers/xen/blkback/blkback.c), when function dispatch_rw_block_io() try to do the real I/O job, it will do a sanity check on I/O request sent from DomU in the following code fragment: ... 430 for (i = 0; i < nseg; i++) { 431 uint32_t flags; 432 433 seg[i].nsec = req->seg[i].last_sect -

Hi Everyone, I''m seeing this message pop up on my console every now and again (or something similar): blkback: ring-ref 8, event-channel 6, protocol 2 (x86_32-abi) Is this a cause for concern? I''m using Xen 4.1.0 from Gitco and using the CentOS Dom0 kernel (2.6.18-238.12.1.el5xen) Any help is appreciated Thanks _______________________________________________ Xen-users

Hi all, I want to use ionice command change the priority of threads of blkback(in domain0) for each corresponding blkfront . However, I do not know how to recognize which is the thread for the corresponding blkfront using ps aux. Anybody can give me some advice? Thanks in advance! -- View this message in context:

Hello Roger Pau Monne, The patch 0a8704a51f38: "xen/blkback: Persistent grant maps for xen blk drivers" from Oct 24, 2012, leads to the following warning: drivers/block/xen-blkfront.c:807 blkif_free() warn: 'persistent_gnt' was already freed. 807 llist_for_each_entry(persistent_gnt, all_gnts, node) { 808

Hello Roger Pau Monne, The patch 0a8704a51f38: "xen/blkback: Persistent grant maps for xen blk drivers" from Oct 24, 2012, leads to the following warning: drivers/block/xen-blkfront.c:807 blkif_free() warn: 'persistent_gnt' was already freed. 807 llist_for_each_entry(persistent_gnt, all_gnts, node) { 808

>>> On 03.04.13 at 15:25, William Dauchy <wdauchy@gmail.com> wrote: > On Wed, Apr 3, 2013 at 3:01 PM, Jan Beulich <JBeulich@suse.com> wrote: >> Iirc we requested the earlier commit to be removed from stable >> trees, and I think Greg also did so. > > I''m sorry but I''m unable to find a revert of 01c681d in stable tree. ChangeLog-3.8.3

I am proposing these two patches for 3.2. They allow the backend to process the REQ_FUA request as well. Previous to these patches it only did REQ_FLUSH. There is also a bug-fix for the logic of how barrier/flushes were handled. The patches are based on a branch which also has ''feature-discard'' patches, so they won''t apply nativly on top of 3.1-rc5. Please review and

Is exporting a block device from one DomU to another supported? ''xm block-attach'' appears to support it based on the command line options displayed but maybe it''s one of those things that doesn''t work because nobody ever uses it? I''m wondering about accessing a VSS snapshot from a windows DomU in Dom0 (or another DomU). In theory, GPLPV should be able