[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Is cache=writeback safe yet?

From: Virtbie
Subject: Re: [Qemu-devel] Is cache=writeback safe yet?
Date: Mon, 20 Feb 2012 18:52:44 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111124 Thunderbird/8.0

On 02/20/12 16:43, Virtbie wrote:

Great explanation Anthony,

may I still ask:

Is WCE + volatile flag exposed to the guest, by all three virtual devices:
- virtio
- scsi
- ide
(if not, I still don't understand how this works)

2) Is there a minimum guest kernel and a minimum viostor Windows driver version, to see such WCE+volatile flag in a virtio disk, so that the guest OS can actually see the cache?

Because I can't seem to find such flag for a virtio disk on a linux 2.6.38 guest and that seems serious to me.
Is it visible somewhere in /sys hierarchy? Or is 2.6.38 too old?

Is it this commit?

commit f1b0ef062602713c2c7cfa12362d5d90ed01c5f6
Author: Christoph Hellwig <address@hidden>
Date:   Thu Sep 17 19:57:42 2009 +0200

    virtio_blk: add support for cache flush

    Recent qemu has added a VIRTIO_BLK_F_FLUSH flag to advertise that the
virtual disk has a volatile write cache that needs to be flushed. In case
    we see this feature implement tell the Linux block layer about the fact
and use the new VIRTIO_BLK_T_FLUSH to flush the cache when required. This
    allows for an correct and simple implementation of write barriers.

    Signed-off-by: Christoph Hellwig <address@hidden>
    Signed-off-by: Rusty Russell <address@hidden>

That was introduced in 2.6.32 .
So can I suppose that a guest running linux 2.6.32+ detects the write cache in a virtio disk and actually flushes? (suppose a wise filesystem)

The flag seems to go into :

    /* Feature bits */
#define VIRTIO_BLK_F_BARRIER 0 /* Does host support barriers? */ #define VIRTIO_BLK_F_SIZE_MAX 1 /* Indicates maximum segment size */ #define VIRTIO_BLK_F_SEG_MAX 2 /* Indicates maximum # of segments */ #define VIRTIO_BLK_F_GEOMETRY 4 /* Legacy geometry available */
    #define VIRTIO_BLK_F_RO         5       /* Disk is read-only */
#define VIRTIO_BLK_F_BLK_SIZE 6 /* Block size of disk is available*/ #define VIRTIO_BLK_F_SCSI 7 /* Supports scsi command passthru */ #define VIRTIO_BLK_F_FLUSH 9 /* Cache flush command support */ #define VIRTIO_BLK_F_TOPOLOGY 10 /* Topology information is available */

    #define VIRTIO_BLK_ID_BYTES     20      /* ID string length */


    static unsigned int features[] = {

so the presence of volatile cache is probably exposed by:

    $ cat /sys/block/vda/device/features

I don't understand if I should look at the 10th bit (9 in 0-based as per #define's ) which would be 0 == "no cache" in this case, or at the 7th bit (by the position in features[] array), which would be 1 == "has cache" in this case .

Thank you

reply via email to

[Prev in Thread] Current Thread [Next in Thread]