Qemu drive cache Option

Aus Thomas-Krenn-Wiki
Zur Navigation springen Zur Suche springen

Quick Emulator (QEMU) ist ein Open Source Emulator, der unter anderem virtuelle Hardware emuliert. QEMU kann gemeinsam mit KVM genutzt werden und kommt auf diese Art bei Proxmox VE zum Einsatz. In diesem Artikel geht es grundsätzlich um die QEMU drive Option "cache". Die Konfiguration eines QEMU drive enthält die Erzeugung eines block driver nodes (backend) sowie eines Gastgeräts.

cache Option

Die Option "cache" steuert wie der Host-Cache für den Zugriff auf Blockdaten verwendet wird.

Die Option "cache" ist eine Verknüpfung, welche die drei Optionen cache.direct, cache.no-flush (beide wie in -blockdev) sowie zusätzlich cache.writeback (-device) festlegt. Die fünf cache-Modi writeback, none, writethrough, directsync und unsafe entsprechen den folgenden Einstellungen:[1]

cache -device Option -blockdev Optionen Anmerkungen[2]
Name QEMU Name Proxmox VE GUI cache.writeback cache.direct cache.no-flush Gewährleistung Datenintegrität nach einem plötzlichen Ausfall des Hosts Schreib-Performance
writeback Write back ✔ (on) - - Hoch, wenn das Gast-Betriebssystem/Dateisystem regelmäßig den Cache-Inhalt auf Disk schreibt (flush). Dies wird von modernen Dateisystemen in der Regel automatisch durchgeführt. Siehe dazu auch Ext4 Write Barriers. Pagecache des Hosts wird verwendet. Hoch
none No cache ✔ (on) ✔ (on) - Pagecache des Hosts wird nicht verwendet. Dennoch können sich Daten in anderen Caches (z.B. Cache einer HDD) befinden. Daher muss das Gast-Betriebssystem dennoch regelmäßig flushes durchführen.
writethrough Write through - - - Sehr hoch, da QEMU mit Cache Modus "writethrough" Daten niemals in einem "Schreibcache" speichert, sondern nach jedem Schreibvorgang die Funktion fsync() aufruft. Pagecache des Hosts wird verwendet. Geringer, da nach jedem Schreibvorgang die Funktion fsync() aufgerufen wird.
directsync Direct sync - ✔ (on) - Pagecache des Hosts wird nicht verwendet.
unsafe Write back (unsafe) ✔ (on) - ✔ (on) Keine Gewährleistung der Datenintegrität! Hohes Risiko eines Datenverlustes!

Dieser Caching-Modus soll nur für temporäre Daten verwendet werden, bei denen Datenverlust kein Problem darstellt. Dieser Modus kann zur Beschleunigung von Gastinstallationen nützlich sein, danach sollte aber in Produktionsumgebungen unbedingt zu einem anderen Caching-Modus gewechselt werden.[3]

Pagecache des Hosts wird verwendet. Am höchsten

Der Standardmodus in Qemu ist cache=writeback. Bei Proxmox VE wird none (No cache) als Standard verwendet.

cache.writeback

Standardmäßig wird der Modus cache.writeback=on verwendet. Dabei werden Datenschreibvorgänge als abgeschlossen gemeldet, sobald die Daten im Host-Pagecache vorhanden sind. Dies ist sicher, solange Ihr Gastbetriebssystem dafür sorgt, dass die Festplatten-Caches bei Bedarf korrekt geleert werden. Wenn Ihr Gastbetriebssystem volatile Festplatten-Schreib-Caches nicht korrekt verarbeitet und Ihr Host abstürzt oder die Stromversorgung ausfällt, kann es zu Datenbeschädigungen im Gastbetriebssystem kommen.

Für solche Gäste sollten Sie die Verwendung von cache.writeback=off in Betracht ziehen. Das bedeutet, dass der Host-Pagecache zum Lesen und Schreiben von Daten verwendet wird, aber die Schreibbenachrichtigung erst dann an den Gast gesendet wird, nachdem QEMU sichergestellt hat, dass jeder Schreibvorgang auf die Festplatte geleert wurde. Beachten Sie, dass dies erhebliche Auswirkungen auf die Leistung hat.[4]

Disk (Einstellung Proxmox VE GUI) Abfrage Cache via Ergebnis bei cache.writeback=on Ergebnis bei cache.writeback=off Anmerkung
IDE hdparm -I /dev/sdc | grep "Write cache" * Write cache Write cache (kein Stern davor) hdparm führt ein ATA IDENTIFY DEVICE Kommando aus, um die Einstellung abzufragen.
SATA
VirtIO Block cat /sys/block/vda/queue/write_cache write back write through Der VirtIO Block Treiber stellt die Information via sysfs zur Verfügung.
SCSI sdparm --get=WCE /dev/sda WCE = 1 WCE = 0 sdparm führt ein SCSI MODE SENSE Kommando aus, um die Einstellung abzufragen. WCE steht dabei für "Writeback Cache Enable".

chache.direct

cache.direct=on umgeht den Host Pagecache. Dadurch wird versucht, die Disk-I/O direkt im Memory des Gasts auszuführen. QEMU führt möglicherweise weiterhin eine interne Kopie der Daten durch.

cache.no-flush

cache.no-flush (Achtung - Gefahr von Datenverlust! - nur verwenden, wenn Datenintegrität nicht wichtig ist, etwa bei reinen Tests) teilt QEMU mit, dass es niemals Daten auf die Festplatte schreiben muss, sondern stattdessen alles im Cache speichern kann. Wenn etwas schief geht, z. B. wenn Ihr Host keinen Strom mehr hat, die Festplatte versehentlich getrennt wird usw., wird Ihr Image höchstwahrscheinlich unbrauchbar.

Tests

Die folgenden Tests sind auf einem lvmthin Volume durchgeführt worden. Diese unterstützen ausschließlich raw (kein qcow2).[5] Für Hintergründe zu cache=none bei qcow2 verweisen wir auf den Beitrag "Understanding QCOW2 Risks with QEMU cache=none in Proxmox".[6]

Mit dem diskchecker.pl Perl Skript haben wir getestet, ob Daten bei einem Stromausfall verloren gehen können. Hintergrundinformationen zu diesem Skript gibt es hier: http://brad.livejournal.com/2116715.html

Debian 13 VM mit raw
Cache Einstellung diskchecker.pl Ergebnis
Default (No cache) Total errors: 0
Write back (unsafe) Total errors: 2786
Write through Total errors: 0
Write back Total errors: 0
Direct sync Total errors: 0

Default (No cache)

tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 create test_file 1000
  diskchecker: running 1 sec, 0.46% coverage of 1000 MB (293 writes; 293/s)
  diskchecker: running 2 sec, 1.06% coverage of 1000 MB (684 writes; 342/s)
  diskchecker: running 3 sec, 1.70% coverage of 1000 MB (1099 writes; 366/s)
  diskchecker: running 4 sec, 2.33% coverage of 1000 MB (1507 writes; 376/s)
  diskchecker: running 5 sec, 2.93% coverage of 1000 MB (1907 writes; 381/s)
  diskchecker: running 6 sec, 3.58% coverage of 1000 MB (2326 writes; 387/s)
  diskchecker: running 7 sec, 4.20% coverage of 1000 MB (2739 writes; 391/s)
  diskchecker: running 8 sec, 4.81% coverage of 1000 MB (3152 writes; 394/s)
  diskchecker: running 9 sec, 5.40% coverage of 1000 MB (3553 writes; 394/s)
  diskchecker: running 10 sec, 6.03% coverage of 1000 MB (3976 writes; 397/s)
[...]
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 verify test_file 
 verifying: 0.03%
 verifying: 46.22%
 verifying: 100.00%
Total errors: 0
tk@debian13-1:~$

Write back (unsafe)

tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 create test_file_unsafe 1000
  diskchecker: running 1 sec, 0.45% coverage of 1000 MB (286 writes; 286/s)
  diskchecker: running 2 sec, 1.22% coverage of 1000 MB (782 writes; 391/s)
  diskchecker: running 3 sec, 2.06% coverage of 1000 MB (1328 writes; 442/s)
  diskchecker: running 4 sec, 2.81% coverage of 1000 MB (1820 writes; 455/s)
  diskchecker: running 5 sec, 3.55% coverage of 1000 MB (2306 writes; 461/s)
  diskchecker: running 6 sec, 4.25% coverage of 1000 MB (2778 writes; 463/s)
  diskchecker: running 7 sec, 5.04% coverage of 1000 MB (3302 writes; 471/s)
  diskchecker: running 8 sec, 5.85% coverage of 1000 MB (3863 writes; 482/s)
  diskchecker: running 9 sec, 6.73% coverage of 1000 MB (4466 writes; 496/s)
  diskchecker: running 10 sec, 7.50% coverage of 1000 MB (4984 writes; 498/s)
[...]
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 verify test_file_unsafe 
 verifying: 0.02%
  Error at page 26, 4 seconds before end.
  Error at page 34, 6 seconds before end.
  Error at page 49, 3 seconds before end.
  Error at page 123, 0 seconds before end.
  Error at page 166, 0 seconds before end.
  Error at page 167, 6 seconds before end.
  Error at page 169, 1 seconds before end.
  Error at page 199, 1 seconds before end.
  Error at page 200, 2 seconds before end.
  Error at page 214, 4 seconds before end.
[...]
 verifying: 100.00%
Total errors: 2786
Histogram of seconds before end:
     0  420
     1  478
     2  339
     3  285
     4  303
     5  351
     6  354
     7  256
tk@debian13-1:~$

Write through

tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 create test_file_writethrough 1000
  diskchecker: running 1 sec, 0.36% coverage of 1000 MB (234 writes; 234/s)
  diskchecker: running 2 sec, 0.92% coverage of 1000 MB (587 writes; 293/s)
  diskchecker: running 3 sec, 1.45% coverage of 1000 MB (929 writes; 309/s)
  diskchecker: running 4 sec, 1.97% coverage of 1000 MB (1268 writes; 317/s)
  diskchecker: running 5 sec, 2.49% coverage of 1000 MB (1612 writes; 322/s)
  diskchecker: running 6 sec, 3.02% coverage of 1000 MB (1957 writes; 326/s)
  diskchecker: running 7 sec, 3.53% coverage of 1000 MB (2295 writes; 327/s)
  diskchecker: running 8 sec, 4.07% coverage of 1000 MB (2650 writes; 331/s)
  diskchecker: running 9 sec, 4.57% coverage of 1000 MB (2989 writes; 332/s)
  diskchecker: running 10 sec, 5.07% coverage of 1000 MB (3327 writes; 332/s)
[...]
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 verify test_file_writethrough 
 verifying: 0.02%
 verifying: 56.67%
 verifying: 100.00%
Total errors: 0
tk@debian13-1:~$

Write back

tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 create test_file_writeback 1000
  diskchecker: running 1 sec, 0.45% coverage of 1000 MB (289 writes; 289/s)
  diskchecker: running 2 sec, 1.03% coverage of 1000 MB (671 writes; 335/s)
  diskchecker: running 3 sec, 1.62% coverage of 1000 MB (1051 writes; 350/s)
  diskchecker: running 4 sec, 2.21% coverage of 1000 MB (1438 writes; 359/s)
  diskchecker: running 5 sec, 2.82% coverage of 1000 MB (1831 writes; 366/s)
  diskchecker: running 6 sec, 3.40% coverage of 1000 MB (2224 writes; 370/s)
  diskchecker: running 7 sec, 3.98% coverage of 1000 MB (2611 writes; 373/s)
  diskchecker: running 8 sec, 4.56% coverage of 1000 MB (3005 writes; 375/s)
  diskchecker: running 9 sec, 5.15% coverage of 1000 MB (3397 writes; 377/s)
  diskchecker: running 10 sec, 5.73% coverage of 1000 MB (3788 writes; 378/s)
[...]
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 verify test_file_writeback 
 verifying: 0.03%
 verifying: 47.70%
 verifying: 100.00%
Total errors: 0
tk@debian13-1:~$

Direct sync

tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 create test_file_directsync 1000
  diskchecker: running 1 sec, 0.38% coverage of 1000 MB (246 writes; 246/s)
  diskchecker: running 2 sec, 0.90% coverage of 1000 MB (579 writes; 289/s)
  diskchecker: running 3 sec, 1.49% coverage of 1000 MB (960 writes; 320/s)
  diskchecker: running 4 sec, 2.01% coverage of 1000 MB (1302 writes; 325/s)
  diskchecker: running 5 sec, 2.53% coverage of 1000 MB (1643 writes; 328/s)
  diskchecker: running 6 sec, 3.08% coverage of 1000 MB (2006 writes; 334/s)
  diskchecker: running 7 sec, 3.61% coverage of 1000 MB (2363 writes; 337/s)
  diskchecker: running 8 sec, 4.16% coverage of 1000 MB (2721 writes; 340/s)
  diskchecker: running 9 sec, 4.74% coverage of 1000 MB (3108 writes; 345/s)
  diskchecker: running 10 sec, 5.26% coverage of 1000 MB (3463 writes; 346/s)
[...]
tk@debian13-1:~$ ./diskchecker.pl -s 172.16.0.112 verify test_file_directsync 
 verifying: 0.01%
 verifying: 57.56%
 verifying: 100.00%
Total errors: 0
tk@debian13-1:~$

Weitere Informationen

Einzelnachweise

  1. ↑ QEMU User Documentation (Manpage) - Block device options (www.qemu.org/docs) cache is “none”, “writeback”, “unsafe”, “directsync” or “writethrough” and controls how the host cache is used to access block data. This is a shortcut that sets the cache.direct and cache.no-flush options (as in -blockdev), and additionally cache.writeback, which provides a default for the write-cache option of block guest devices (as in -device).
  2. ↑ libvirt: Use 'writeback' QEMU cache mode when 'none' is not viable (opendev.org/openstack/nova, 04.05.2019) The thing that makes 'writethrough' so safe against host crashes is that it never keeps data in a "write cache", but it calls fsync() after _every_ write. This is also what makes it horribly slow. But 'cache=none' doesn't do this and therefore doesn't provide this kind of safety. The guest OS must explicitly flush the cache in the right places to make sure data is safe on the disk. And OSes do that.
    So if 'cache=none' is safe enough for you, then 'cache=writeback' should be safe enough for you, too -- because both of them have the boolean 'cache.writeback=on'. The difference is only in 'cache.direct', but 'cache.direct=on' only bypasses the host kernel page cache and data could still sit in other caches that could be present between QEMU and the disk (such as commonly a volatile write cache on the disk itself).
  3. ↑ https://opendev.org/openstack/nova/src/commit/18a7dcb6e816e26e405259e981498f6a7bc71608/nova/conf/libvirt.py#L724
  4. ↑ QEMU User Documentation (Manpage) - Block device options (www.qemu.org/docs) By default, the cache.writeback=on mode is used. It will report data writes as completed as soon as the data is present in the host page cache. This is safe as long as your guest OS makes sure to correctly flush disk caches where needed. If your guest OS does not handle volatile disk write caches correctly and your host crashes or loses power, then the guest may experience data corruption.
    For such guests, you should consider using cache.writeback=off. This means that the host page cache will be used to read and write data, but write notification will be sent to the guest only after QEMU has made sure to flush each write to the disk. Be aware that this has a major impact on performance.
  5. ↑ https://forum.proxmox.com/threads/proxmox-disks-changed-from-qcow-to-raw-after-migration.96007/#post-417101
  6. ↑ Understanding QCOW2 Risks with QEMU cache=none in Proxmox (kb.blockbridge.com)


Autor: Werner Fischer

Werner Fischer arbeitet im Product Management Team von Thomas-Krenn. Er evaluiert dabei neueste Technologien und teilt sein Wissen in Fachartikeln, bei Konferenzen und im Thomas-Krenn Wiki. Bereits 2005 - ein Jahr nach seinem Abschluss des Studiums zu Computer- und Mediensicherheit an der FH Hagenberg - heuerte er beim bayerischen Server-Hersteller an. Als Öffi-Fan nutzt er gerne Bus & Bahn und genießt seinen morgendlichen Spaziergang ins Büro.

 

Das könnte Sie auch interessieren

Proxmox Datacenter Manager
Zum Artikel
Proxmox Offline Mirror Tool
Zum Artikel
QCOW2 Image - Import in Proxmox VE
Zum Artikel