search for: virtblk_request

...If you simply mark every virtqueue as broken when this > unexpected unplug happens, does that not Just Work? > > I think I've asked this before... > Rusty. Hi Rusty, setting the (one) virtqueue, vblk is currently using, as broken doesn't solve the problems. In that case virtblk_request()s still succeed - like this one... ([<0000000000112b28>] show_trace+0xf8/0x154) [<0000000000112bde>] show_stack+0x5a/0xdc [<000000000045eb56>] virtblk_request+0x25a/0x2b8 [<00000000003e749c>] __blk_run_queue+0x50/0x64 [<00000000003edb54>] blk_queue_bio+0x358...

...If you simply mark every virtqueue as broken when this > unexpected unplug happens, does that not Just Work? > > I think I've asked this before... > Rusty. Hi Rusty, setting the (one) virtqueue, vblk is currently using, as broken doesn't solve the problems. In that case virtblk_request()s still succeed - like this one... ([<0000000000112b28>] show_trace+0xf8/0x154) [<0000000000112bde>] show_stack+0x5a/0xdc [<000000000045eb56>] virtblk_request+0x25a/0x2b8 [<00000000003e749c>] __blk_run_queue+0x50/0x64 [<00000000003edb54>] blk_queue_bio+0x358...

...happens, does that not Just Work? >>> >>> I think I've asked this before... >>> Rusty. >> >> Hi Rusty, >> >> setting the (one) virtqueue, vblk is currently using, as broken doesn't >> solve the problems. >> >> In that case virtblk_request()s still succeed - like this one... > > No, you set *all* virtqueues broken. Which is accurate, right? > > Cheers, > Rusty. > I'm sorry, but I don't get this. The vblk involved has only 1 virtqueue. What do you mean by all "*all* virtqueues ? Heinz >> >&...

...happens, does that not Just Work? >>> >>> I think I've asked this before... >>> Rusty. >> >> Hi Rusty, >> >> setting the (one) virtqueue, vblk is currently using, as broken doesn't >> solve the problems. >> >> In that case virtblk_request()s still succeed - like this one... > > No, you set *all* virtqueues broken. Which is accurate, right? > > Cheers, > Rusty. > I'm sorry, but I don't get this. The vblk involved has only 1 virtqueue. What do you mean by all "*all* virtqueues ? Heinz >> >&...

...>> informs the driver (virtio_ccw) about the lost device. >> >> It's just the block device drivers that care to provide a notify >> callback. >> >> Here are some more error details: >> >> For a particular block device virtio's request function virtblk_request() >> is called by the block layer to queue requests to be handled by the host. >> In case of a lost device requests can still be queued, but an appropriate >> subsequent host kick usually fails. This leads to situations where no error >> feedback is shown. >> >>...

...>> informs the driver (virtio_ccw) about the lost device. >> >> It's just the block device drivers that care to provide a notify >> callback. >> >> Here are some more error details: >> >> For a particular block device virtio's request function virtblk_request() >> is called by the block layer to queue requests to be handled by the host. >> In case of a lost device requests can still be queued, but an appropriate >> subsequent host kick usually fails. This leads to situations where no error >> feedback is shown. >> >>...

...n when this >> unexpected unplug happens, does that not Just Work? >> >> I think I've asked this before... >> Rusty. > > Hi Rusty, > > setting the (one) virtqueue, vblk is currently using, as broken doesn't > solve the problems. > > In that case virtblk_request()s still succeed - like this one... No, you set *all* virtqueues broken. Which is accurate, right? Cheers, Rusty. > > ([<0000000000112b28>] show_trace+0xf8/0x154) > [<0000000000112bde>] show_stack+0x5a/0xdc > [<000000000045eb56>] virtblk_request+0x25a/0x2b8 &g...

...ot-unplugged. The device is removed and no further I/O is possible. When an online channel device disappears on System z the kernel's CIO layer informs the driver (virtio_ccw) about the lost device. Here are some more error details: For a particular block device virtio's request function virtblk_request() is called by the block layer to queue requests to be handled by the host. In case of a lost device requests can still be queued, but an appropriate subsequent host kick usually fails. This leads to situations where no error feedback is shown. In order to prevent request queueing for lost devices...

...ot-unplugged. The device is removed and no further I/O is possible. When an online channel device disappears on System z the kernel's CIO layer informs the driver (virtio_ccw) about the lost device. Here are some more error details: For a particular block device virtio's request function virtblk_request() is called by the block layer to queue requests to be handled by the host. In case of a lost device requests can still be queued, but an appropriate subsequent host kick usually fails. This leads to situations where no error feedback is shown. In order to prevent request queueing for lost devices...

...rtio_ccw) about the lost device. > >> > >>It's just the block device drivers that care to provide a notify > >>callback. > >> > >>Here are some more error details: > >> > >>For a particular block device virtio's request function virtblk_request() > >>is called by the block layer to queue requests to be handled by the host. > >>In case of a lost device requests can still be queued, but an appropriate > >>subsequent host kick usually fails. This leads to situations where no error > >>feedback is shown. &g...

...ine channel device disappears on System z the kernel's CIO layer informs the driver (virtio_ccw) about the lost device. It's just the block device drivers that care to provide a notify callback. Here are some more error details: For a particular block device virtio's request function virtblk_request() is called by the block layer to queue requests to be handled by the host. In case of a lost device requests can still be queued, but an appropriate subsequent host kick usually fails. This leads to situations where no error feedback is shown. In order to prevent request queueing for lost devices...

...ine channel device disappears on System z the kernel's CIO layer informs the driver (virtio_ccw) about the lost device. It's just the block device drivers that care to provide a notify callback. Here are some more error details: For a particular block device virtio's request function virtblk_request() is called by the block layer to queue requests to be handled by the host. In case of a lost device requests can still be queued, but an appropriate subsequent host kick usually fails. This leads to situations where no error feedback is shown. In order to prevent request queueing for lost devices...

...ssible. >> >> When an online channel device disappears on System z the kernel's CIO layer >> informs the driver (virtio_ccw) about the lost device. >> >> Here are some more error details: >> >> For a particular block device virtio's request function virtblk_request() >> is called by the block layer to queue requests to be handled by the host. >> In case of a lost device requests can still be queued, but an appropriate >> subsequent host kick usually fails. This leads to situations where no error >> feedback is shown. >> >>...

...ssible. >> >> When an online channel device disappears on System z the kernel's CIO layer >> informs the driver (virtio_ccw) about the lost device. >> >> Here are some more error details: >> >> For a particular block device virtio's request function virtblk_request() >> is called by the block layer to queue requests to be handled by the host. >> In case of a lost device requests can still be queued, but an appropriate >> subsequent host kick usually fails. This leads to situations where no error >> feedback is shown. >> >>...

...z the kernel's CIO layer > informs the driver (virtio_ccw) about the lost device. > > It's just the block device drivers that care to provide a notify > callback. > > Here are some more error details: > > For a particular block device virtio's request function virtblk_request() > is called by the block layer to queue requests to be handled by the host. > In case of a lost device requests can still be queued, but an appropriate > subsequent host kick usually fails. This leads to situations where no error > feedback is shown. > > In order to prevent req...

...nd no further I/O > is possible. > > When an online channel device disappears on System z the kernel's CIO layer > informs the driver (virtio_ccw) about the lost device. > > Here are some more error details: > > For a particular block device virtio's request function virtblk_request() > is called by the block layer to queue requests to be handled by the host. > In case of a lost device requests can still be queued, but an appropriate > subsequent host kick usually fails. This leads to situations where no error > feedback is shown. > > In order to prevent requ...

...#39;ve asked this before... Rusty. > > When an online channel device disappears on System z the kernel's CIO layer > informs the driver (virtio_ccw) about the lost device. > > Here are some more error details: > > For a particular block device virtio's request function virtblk_request() > is called by the block layer to queue requests to be handled by the host. > In case of a lost device requests can still be queued, but an appropriate > subsequent host kick usually fails. This leads to situations where no error > feedback is shown. > > In order to prevent requ...

Hi, all This version reworked on REQ_FLUSH and REQ_FUA support as suggested by Christoph and dropped the block core bits since Jens has picked them up. Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%,

Hi, all This version reworked on REQ_FLUSH and REQ_FUA support as suggested by Christoph and dropped the block core bits since Jens has picked them up. Fio test shows bio-based IO path gives the following performance improvement: 1) Ramdisk device With bio-based IO path, sequential read/write, random read/write IOPS boost : 28%, 24%, 21%, 16% Latency improvement: 32%,

Hi, Jens & Rusty This version is rebased against linux-next which resolves the conflict with Paolo Bonzini's 'virtio-blk: allow toggling host cache between writeback and writethrough' patch. Patch 1/3 and 2/3 applies on linus's master as well. Since Rusty will pick up patch 3/3 so the changes to block core (adding blk_bio_map_sg()) will have a user. Jens, could you please