[Bug 42939] New: hv_storvsc - write cache enabled by default and cannot be disabled

[Bug 42939] New: hv_storvsc - write cache enabled by default and cannot be disabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42939

           Summary: hv_storvsc - write cache enabled by default and cannot
                    be disabled
           Product: SCSI Drivers
           Version: 2.5
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Other
        AssignedTo: scsi_drivers-other@kernel-bugs.osdl.org
        ReportedBy: bugzilla-kernel-org-sux2k0@mstier.de
        Regression: No


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.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

[Bug 42939] hv_storvsc - write cache enabled by default and cannot be disabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42939


Mark <bugzilla-kernel-org-sux2k0@mstier.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Kernel Version|                            |3.2.11




-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

[Bug 42939] hv_storvsc - write cache enabled by default and cannot be disabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42939





--- Comment #1 from Mark <bugzilla-kernel-org-sux2k0@mstier.de>  2012-03-19 19:33:29 ---
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...??

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

[Bug 42939] hv_storvsc - write cache enabled by default and cannot be disabled

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=42939





--- Comment #2 from Mark <bugzilla-kernel-org-sux2k0@mstier.de>  2012-03-19 19:36:47 ---
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?

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.