Bug 42939 - hv_storvsc - write cache enabled by default and cannot be disabled
Summary: hv_storvsc - write cache enabled by default and cannot be disabled
Status: NEW
Alias: None
Product: SCSI Drivers
Classification: Unclassified
Component: Other (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: scsi_drivers-other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-15 21:55 UTC by Mark
Modified: 2012-03-19 19:36 UTC (History)
0 users

See Also:
Kernel Version: 3.2.11
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Mark 2012-03-15 21:55:58 UTC
dmesg output:

[    8.080401] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, supports DPO and FUA

Question: how safe is my (database) data in the case of a host machine crash or a VM crash?

There is no battery-backed writecache installed in the host, just some cheap and slow SATA disks.

Another curiosity occurs when running the fio iometer benchmark on the same machine: it gives me 5.000 to 6.000 I/O random access operations per second when using the para-virt hv_storvsc driver, but only the expected 200 I/O ops when using ata_piix via emulation.The kernel in question is version 3.2.11.

There doesn't seem to be any way to disable the para-virt device's write-cache.

Kernel version is mainline 3.2.11.
Comment 1 Mark 2012-03-19 19:33:29 UTC
Additional information:

trying to disable the writecache leads to the partition on the SCSI device getting remounted read-only due to device errors.

Additional information (2):

I get 5.000 to 6.000 random reads per second even when manually creating the fiometer file using random data from /dev/urandom (ie. fio doesn't access zeroes in that case).

Additional information (3):

The host doesn't seem to cache anything: "dd iflag=direct if=/dev/sda bs=1M of=/dev/null count=10" always and repeatedly gives me around 30-60 MB/s.

Additional information (4):

I did a simple MySQL InnoDB ACID transaction test where subsequent transactions are done via a remote mysql client as fast as possible. I crashed the host hardware and checked if all transactions reported as completed had been committed to disk: no obvious problems there -- seemingly the reported writecache has no writecache-effects at all...??
Comment 2 Mark 2012-03-19 19:36:47 UTC
Additional information (5):

I'm getting 1.000 subsequent (serialized and small -- integer inserts) transactions done (locally) within 2.2 seconds -- with InnoDB ACID transactions (ie. full data transaction sync enabled). Isn't that a bit too fast for cheap SATA disks in a RAID10 config?

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