Bug 1672680 - virtio-blk: add discard and write zeroes support (qemu-kvm)
Summary: virtio-blk: add discard and write zeroes support (qemu-kvm)
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: qemu-kvm
Version: ---
Hardware: Unspecified
OS: Unspecified
high
unspecified
Target Milestone: rc
: 8.0
Assignee: Stefano Garzarella
QA Contact: CongLi
URL:
Whiteboard:
Depends On: 1692939
Blocks: 1672682
TreeView+ depends on / blocked
 
Reported: 2019-02-05 15:54 UTC by Stefano Garzarella
Modified: 2019-11-06 07:13 UTC (History)
14 users (show)

Fixed In Version: qemu-kvm-4.0.0-1.module+el8.1.0+3225+a8268fde
Doc Type: Enhancement
Doc Text:
Clone Of:
: 1672682 1692939 (view as bug list)
Environment:
Last Closed: 2019-11-06 07:12:49 UTC
Type: Feature Request
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:3723 None None None 2019-11-06 07:13:21 UTC

Description Stefano Garzarella 2019-02-05 15:54:38 UTC
Add the support of DISCARD and WRITE ZEROES commands, that have been introduced in the virtio-blk protocol to have better performance when using SSD backend.
Linux driver (guest) already supports these features.

Comment 1 Stefano Garzarella 2019-03-12 16:04:49 UTC
The series is upstream and these features will be included in QEMU 4.0

https://www.mail-archive.com/qemu-devel@nongnu.org/msg598631.html

The series adds the support of DISCARD and WRITE_ZEROES commands and extends the virtio-blk-test to test these new commands.

Comment 5 CongLi 2019-05-24 10:49:01 UTC
(Reply to the Recording from Stefano in Epic)
  (Recording from Stefano in Epic )
    (Recording from Cong Li in Epic)

Hi Stefano,

Sorry for the late reply.

> > 1. I saw the updates in tests/virtio-blk-test.c when I checked 
> > the commit log, but actually QE do not use it for our testing, and 
> > I have no idea how the test scenario is, is it possible for you to 
> >help describe the steps then QE could new a test case in polarion and test it ?

> Sure!
> What is the QE environment?
> If you want to test the features in a Linux guest, it is not simple 
> because a lot of things are hidden to the user-space. (e. g. what I 
> said for 'blkdiscard -z /dev/vda' to test write-zeroes). For this 
> reason, the QEMU tests use the libqos 
> (https://wiki.qemu.org/Features/qtest_driver_framework)

Generally, only a fresh installed guest.
No such qtest driver framework. 

> > 3. I still would like to confirm how to test max-discard-sectors 
> > and max-write-zeroes-sectors, what's the difference if I set different 
> > values, how to confirm it in the testing?

> These values control the maximum size per-request that the driver can do, 
> so for example, if you set 1, the operation will be very slow, because the 
> driver must send multiple requests. Also in this case, they are hidden to 
> the user-space.

Is there a reference for the performance improvement ?


Thanks.

Comment 6 Stefano Garzarella 2019-05-27 13:42:58 UTC
(In reply to CongLi from comment #5)
> (Reply to the Recording from Stefano in Epic)
>   (Recording from Stefano in Epic )
>     (Recording from Cong Li in Epic)
> 
> Hi Stefano,
> 
> Sorry for the late reply.
> 
> > > 1. I saw the updates in tests/virtio-blk-test.c when I checked 
> > > the commit log, but actually QE do not use it for our testing, and 
> > > I have no idea how the test scenario is, is it possible for you to 
> > >help describe the steps then QE could new a test case in polarion and test it ?
> 
> > Sure!
> > What is the QE environment?
> > If you want to test the features in a Linux guest, it is not simple 
> > because a lot of things are hidden to the user-space. (e. g. what I 
> > said for 'blkdiscard -z /dev/vda' to test write-zeroes). For this 
> > reason, the QEMU tests use the libqos 
> > (https://wiki.qemu.org/Features/qtest_driver_framework)
> 
> Generally, only a fresh installed guest.
> No such qtest driver framework. 

Okay, so in this case, the only tests that you can do are the ones that I mentioned:
- discard
  # when discard disabled
  $ blkdiscard /dev/vda && echo "PASS" || echo "FAIL"
    blkdiscard: /dev/vda: BLKDISCARD ioctl failed: Operation not supported
    FAIL

  # when discard enabled
  $ blkdiscard /dev/vda && echo "PASS" || echo "FAIL"
    PASS

- write-zeroes
  $ dd if=/dev/urandom of=/dev/vda bs=64k conv=fsync    # fill the disk with random bytes
  $ dd if=/dev/vda bs=64k | tr -d '\0' | read -n 1 && echo "PASS (not all zeroes)" || echo "FAIL"
    PASS (not all zeroes)

  $ blkdiscard -z /dev/vda
  $ dd if=/dev/vda bs=64k | tr -d '\0' | read -n 1 && echo "FAIL" || echo "PASS (All zeroes)"
    81920+0 records in
    81920+0 records out
    PASS (All zeroes)

  Unfortunately, this test works also if write-zeroes is disabled because the Linux I/O subsystem will emulate the write-zeroes operation with a simple write.

> 
> > > 3. I still would like to confirm how to test max-discard-sectors 
> > > and max-write-zeroes-sectors, what's the difference if I set different 
> > > values, how to confirm it in the testing?
> 
> > These values control the maximum size per-request that the driver can do, 
> > so for example, if you set 1, the operation will be very slow, because the 
> > driver must send multiple requests. Also in this case, they are hidden to 
> > the user-space.
> 
> Is there a reference for the performance improvement ?

No, but I did some tests and I have these values using a raw image (5 GiB):
- max-discard-sectors=1
  $ time blkdiscard /dev/vda
    real  0m 12.59s
    user  0m 0.00s
    sys   0m 4.14s

- max-discard-sectors=4194303
  $ time blkdiscard /dev/vda
    real  0m 0.00s
    user  0m 0.00s
    sys   0m 0.00s

- max-write-zeroes-sectors=1
  $ time blkdiscard -z /dev/vda
    real  1m 1.33s
    user  0m 0.00s
    sys   0m 7.19s

- max-write-zeroes-sectors=4194303
  $ time blkdiscard -z /dev/vda
    real  0m 0.59s
    user  0m 0.00s
    sys   0m 0.00s

I hope this can help.

Comment 8 CongLi 2019-06-03 02:09:00 UTC
Verified this bug on:
kernel-4.18.0-96.el8.x86_64
qemu-kvm-4.0.0-2.module+el8.1.0+3258+4c45705b.x86_64

Same steps as BZ1692939#c6.

Thanks.

Comment 10 errata-xmlrpc 2019-11-06 07:12:49 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:3723


Note You need to log in before you can comment on or make changes to this bug.