similar to: [PATCH 6/6] virtio_blk: revert QUEUE_FLAG_VIRT addition

From: Christoph Hellwig <hch at lst.de> It seems like the addition of QUEUE_FLAG_VIRT caueses major performance regressions for Fedora users: https://bugzilla.redhat.com/show_bug.cgi?id=509383 https://bugzilla.redhat.com/show_bug.cgi?id=505695 while I can't reproduce those extreme regressions myself I think the flag is wrong. Rationale: QUEUE_FLAG_VIRT expands to

From: Christoph Hellwig <hch at lst.de> It seems like the addition of QUEUE_FLAG_VIRT caueses major performance regressions for Fedora users: https://bugzilla.redhat.com/show_bug.cgi?id=509383 https://bugzilla.redhat.com/show_bug.cgi?id=505695 while I can't reproduce those extreme regressions myself I think the flag is wrong. Rationale: QUEUE_FLAG_VIRT expands to

(Sorry for delay, recent absences, but all been in linux-next a week now) The following changes since commit 2fdc246aaf9a7fa088451ad2a72e9119b5f7f029: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../bp/bp are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master Christian

(Sorry for delay, recent absences, but all been in linux-next a week now) The following changes since commit 2fdc246aaf9a7fa088451ad2a72e9119b5f7f029: Linus Torvalds (1): Merge branch 'for-linus' of git://git.kernel.org/.../bp/bp are available in the git repository at: ssh://master.kernel.org/pub/scm/linux/kernel/git/rusty/linux-2.6-for-linus.git master Christian

On Thu, Jul 23, 2020 at 11:32:39AM +0100, Stefan Hajnoczi wrote: > On Thu, Jul 16, 2020 at 11:33:44AM +0200, Stefano Garzarella wrote: > > +Cc Michael, Stefan, virtualization at lists.linux-foundation.org > > > > On Thu, Jul 16, 2020 at 09:06:14AM +0100, Richard W.M. Jones wrote: > > > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1857515 > > >

+Cc Michael, Stefan, virtualization at lists.linux-foundation.org On Thu, Jul 16, 2020 at 09:06:14AM +0100, Richard W.M. Jones wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1857515 > > A virtio-blk disk which is backed by a raw file on an SSD, > inside the guest shows rotational = 1. > > I assumed that qemu must have a "rotational" property for disks and

+Cc Michael, Stefan, virtualization at lists.linux-foundation.org On Thu, Jul 16, 2020 at 09:06:14AM +0100, Richard W.M. Jones wrote: > > https://bugzilla.redhat.com/show_bug.cgi?id=1857515 > > A virtio-blk disk which is backed by a raw file on an SSD, > inside the guest shows rotational = 1. > > I assumed that qemu must have a "rotational" property for disks and

On Thu, Jul 16, 2020 at 11:33:44AM +0200, Stefano Garzarella wrote: > +Cc Michael, Stefan, virtualization at lists.linux-foundation.org > > On Thu, Jul 16, 2020 at 09:06:14AM +0100, Richard W.M. Jones wrote: > > > > https://bugzilla.redhat.com/show_bug.cgi?id=1857515 > > > > A virtio-blk disk which is backed by a raw file on an SSD, > > inside the guest

Add virtblk_notify() as virtio_driver's notify() callback. When a transport driver is notified that a device disappeared it should invoke this callback to prevent further request queueing. Subsequent block layer calls of virtio_blk's request function will fail, resulting in appropriate I/O errors. Signed-off-by: Heinz Graalfs <graalfs at linux.vnet.ibm.com> ---

On Thu, 8 Oct 2020 at 17:50, Nicolas Kovacs <info at microlinux.fr> wrote: > Hi, > > This is probably a bit OT, but here goes. > > I've been running our local school's mail server since 2013, with mail > addresses for school staff and some teachers. The server is running CentOS > 7 > with Postfix and Dovecot, and it's a nice no-bullshit configuration with

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

On Fri, Mar 30, 2018 at 08:49:34AM +0800, Changpeng Liu wrote: > Existing virtio-blk protocol doesn't have DISCARD/WRITE ZEROES > command support, this will impact the performance when using SSD > backend over file systems. > > The idea here is using 16 Bytes payload as one descriptor for > DISCARD/WRITE ZEROES command, users can put several ranges into > one command, for

Existing virtio-blk protocol doesn't have DISCARD/WRITE ZEROES commands support, this will impact the performance when using SSD backend over file systems. Commit 88c85538 "virtio-blk: add discard and write zeroes features to specification"(see https://github.com/oasis-tcs/virtio-spec) extended existing virtio-blk protocol, adding extra DISCARD and WRITE ZEROES commands support.

On 9/10/20 11:08 am, Stephen John Smoogen wrote: > On Thu, 8 Oct 2020 at 17:50, Nicolas Kovacs <info at microlinux.fr> wrote: > >> Hi, >> >> This is probably a bit OT, but here goes. >> >> I've been running our local school's mail server since 2013, with mail >> addresses for school staff and some teachers. The server is running CentOS

Previously after device_add_disk returns, the KOBJ_ADD uevent is already emitted. Adding attributes after that is a poor usage of kobject, and in practice may result in race conditions with userspace, for example udev checks availability of certain attributes and initializes /dev entries conditionally. device_add_disk can handle adding attribute group better, so use it. Meanwhile, update the

Hello, On (08/17/16 15:15), Fam Zheng wrote: [..] > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > index 20920a2..2331788 100644 > --- a/drivers/block/zram/zram_drv.c > +++ b/drivers/block/zram/zram_drv.c > @@ -1298,13 +1298,10 @@ static int zram_add(void) > zram->disk->queue->limits.discard_zeroes_data = 0; >

On 28/03/2017 10:39, Changpeng Liu wrote: > + if (virtio_has_feature(vdev, VIRTIO_BLK_F_DISCARD)) { > + q->limits.discard_zeroes_data = 0; Maybe you could use another feature bit to populate discard_zeroes_data. Paolo > + q->limits.discard_alignment = blk_size; > + q->limits.discard_granularity = blk_size; > + blk_queue_max_discard_sectors(q, UINT_MAX); > +

Hello, On (08/17/16 15:15), Fam Zheng wrote: [..] > diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c > index 20920a2..2331788 100644 > --- a/drivers/block/zram/zram_drv.c > +++ b/drivers/block/zram/zram_drv.c > @@ -1298,13 +1298,10 @@ static int zram_add(void) > zram->disk->queue->limits.discard_zeroes_data = 0; >

Existing virtio-blk protocol doesn't have DISCARD/WRITE ZEROES commands support, this will impact the performance when using SSD backend over file systems. Commit 88c85538 "virtio-blk: add discard and write zeroes features to specification"(see https://github.com/oasis-tcs/virtio-spec) extended existing virtio-blk protocol, adding extra DISCARD and WRITE ZEROES commands support.

Existing virtio-blk protocol doesn't have DISCARD/WRITE ZEROES commands support, this will impact the performance when using SSD backend over file systems. Commit 88c85538 "virtio-blk: add discard and write zeroes features to specification"(see https://github.com/oasis-tcs/virtio-spec) extended existing virtio-blk protocol, adding extra DISCARD and WRITE ZEROES commands support.