[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:
1)
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[] = {
VIRTIO_BLK_F_SEG_MAX, VIRTIO_BLK_F_SIZE_MAX,
VIRTIO_BLK_F_GEOMETRY,
VIRTIO_BLK_F_RO, VIRTIO_BLK_F_BLK_SIZE, VIRTIO_BLK_F_SCSI,
VIRTIO_BLK_F_FLUSH, VIRTIO_BLK_F_TOPOLOGY
};
so the presence of volatile cache is probably exposed by:
$ cat /sys/block/vda/device/features
0010101101100000000000000000100000000000000000000000000000000000
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
Vb.