OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [virtio-comment] [PATCH 2/5] virtio-blk spec: writeback cache enable improvements

Il 19/08/2013 17:25, Michael S. Tsirkin ha scritto:
> On Mon, Aug 19, 2013 at 05:09:37PM +0200, Paolo Bonzini wrote:
>> Il 19/08/2013 17:03, James Bottomley ha scritto:
>>> On Mon, 2013-08-19 at 11:55 +0200, Paolo Bonzini wrote:
>>>> This patch introduces two improvements to writeback cache handling
>>>> in the virtio-blk spec.
>>>> 1) The VIRTIO_BLK_F_FLUSH feature is renamed to VIRTIO_BLK_F_WCE, and
>>>> QEMU's behavior is documented explicitly as part of the spec: the host
>>>> negotiates the feature only if its cache is writeback.  The obvious dual
>>>> requirement is imposed on the guest: it should negotiate the feature
>>>> only if it is able to send flushes.  And in order to protect against
>>>> data loss, the spec now mandates that the host operates in writethrough
>>>> mode if the guest does not negotiate VIRTIO_BLK_F_WCE (this behavior
>>>> was already _allowed_ by the spec so far).  This can change with every
>>>> reset of course; typically the BIOS will run as writethrough, while the
>>>> "main" OS will run in writeback mode.  This is a backwards-compatible
>>>> refinement geared towards old or limited guests, so there is no need
>>>> for a new feature bit.
>>>> 2) a second feature is added, VIRTIO_BLK_F_CONFIG_WCE, that provides
>>>> the same information in the configuration.  This will enable the driver
>>>> to modify the write-cache setting at runtime (via sysfs for Linux, via
>>>> MODE SELECT for Windows).
>>> I've got to say this looks cockeyed; you're effectively translating SCSI
>>> commands into your own command set:
>> Note that this is only for Windows, because all block drivers in Windows
>> must speak SCSI.  Microsoft provides an ATA->SCSI translataion layer,
>> while for everything else you're on your own.  For what it's worth, Xen
>> paravirtualized drivers for Windows have to do the same dance.
>> On Linux, there's no MODE SELECT involved, as the commit message says.
>>> the way you're setting this up you
>>> have to modify the driver for every spec feature you support
>> Yes, that's known and that's one of the reasons why virtio-scsi was born.
>>> and have
>>> some sort of elaborate protocol to identify the supported feature set.
>> It's not elaborate (it's just a feature bit), but that's indeed another
>> of the reasons why virtio-scsi was born.
>>> What does this buy you?
>> Nothing, which is why virtio-scsi does it...
>>> SCSI is already a packet transport protocol.
>>> Just transport the SCSI commands over the virtio-interface and let the
>>> server reply (with I don't know what you're talking about if the command
>>> isn't supported).  This is the way SCSI probes real device, so if you do
>>> it this way there's no need for the elaborate protocol identification
>>> and SCSI will work out what the supported feature set is.
>> ... exactly this way.
> Hmm can VIRTIO_BLK_F_SCSI work for this somehow?

No, it cannot.  First of all, it only works for virtio-blk devices
backed by a physical disk (not a logical volume, not a partition, not a
file).  That's a feature, not a bug, since we do not want virtio-blk
devices to carry a SCSI target implementation (QEMU's is 2.5 kSLOC).

Second, any change you make through SCSI requests is not visible to the
host.  For example, if the guest kernel used SCSI requests to enable
writeback caching, the host would not know about it and will not send
flushes (thus a power loss will eat data).

These reasons are why Windows drivers make no attempt to use
VIRTIO_BLK_F_SCSI, they just ignore it and emulate the handful of
commands that Windows actually uses (basically INQUIRY, READ CAPACITY,

VIRTIO_BLK_F_SCSI is a huge hack.  There are some cases where it's
useful if you're stuck with virtio-blk, but if you need it it's probably
a better idea to migrate to virtio-scsi.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]