From: Stefan Hajnoczi <stefanha@redhat.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: "Michael S. Tsirkin" <mst@redhat.com>,
virtualization@lists.linux-foundation.org,
qemu-discuss@nongnu.org
Subject: Re: Interesting qemu/virt-manager bug about the "rotational" attribute on virtio-blk disks
Date: Thu, 23 Jul 2020 11:32:39 +0100 [thread overview]
Message-ID: <20200723103239.GD186372@stefanha-x1.localdomain> (raw)
In-Reply-To: <20200716093344.7molwklwco4sdtvs@steredhat>
[-- Attachment #1.1: Type: text/plain, Size: 1754 bytes --]
On Thu, Jul 16, 2020 at 11:33:44AM +0200, Stefano Garzarella wrote:
> +Cc Michael, Stefan, virtualization@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
> > this would be communicated by virtio to the guest, but qemu and virtio
> > don't seem to have this. Pretty surprising! Is it called something
> > other than "rotational"?
> >
>
> I'm not sure if we need to add this property in QEMU, but in Linux
> I found these flags (include/linux/blkdev.h) for the block queues:
>
> #define QUEUE_FLAG_NONROT 6 /* non-rotational device (SSD) */
> #define QUEUE_FLAG_VIRT QUEUE_FLAG_NONROT /* paravirt device */
>
> xen-blkfront driver is the only one that sets the QUEUE_FLAG_VIRT,
> should we do the same in the virtio-blk driver regardless of the backend?
The ability to control this flag would be interesting for performance
experiments.
The problem with changing the default is that regressions can be
expected. Certain workloads benefit while others regress.
I suggest:
1. Make it controllable so that QUEUE_FLAG_NONROT can be set or clear
(not hardcoded to a single value).
2. The device can communicate the optimal setting from the host. The
SCSI protocol already conveys this information. Virtio-blk needs a
feature bit and possibly config space field.
3. Make it migration-safe. It needs to be configured explicitly so the
value doesn't change suddenly across migration.
Stefan
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
[-- Attachment #2: Type: text/plain, Size: 183 bytes --]
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization
next prev parent reply other threads:[~2020-07-23 10:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200716080614.GA18456@redhat.com>
2020-07-16 9:33 ` Interesting qemu/virt-manager bug about the "rotational" attribute on virtio-blk disks Stefano Garzarella
2020-07-23 10:32 ` Stefan Hajnoczi [this message]
2020-07-23 10:40 ` Richard W.M. Jones
2020-07-23 11:15 ` Stefano Garzarella
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200723103239.GD186372@stefanha-x1.localdomain \
--to=stefanha@redhat.com \
--cc=mst@redhat.com \
--cc=qemu-discuss@nongnu.org \
--cc=sgarzare@redhat.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).