blob: 03917bbf89f5f6af64ecdbbc2da86bf971f7dd75 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
|
---
tags:
- linux
- qemu
- filesystem
references:
- https://avidandrew.com/understanding-disk-cache-writeback-ext4.html
- https://docs.kernel.org/admin-guide/sysctl/vm.html#dirty-expire-centisecs
---
normal: write() -> cache (multiple layers) -> disk
# Physical server write cache
![[physical_write_cache.png]]
Page cache -> RAM
Journal -> ensures data is fully written before the transaction is considered complete.
`commit` mount option -> flushes cache to disk every x seconds (configurable), ==default = 5.==
`barrier` mount option -> enables the ordering of groups of writes, controller ensures writes before barrier are written before writes after barrier. ==Default = 1==
`commit` + dirty_expire_centisecs [2] ~ automatic persisting of data.
If we call `sync`, `fsync` or `fdatasync` ourselves our data is forced on-disk right away by the kernel, no need to wait for commit + dirty_expirty_centisecs.
# VM Write cache
Guest has its own page cache
![[vm_write_cache.png]]
QEMU/KVM options for disk caches:
- Writeback -> write complete if in host page cache; guest required to flush for integrity.
- Writethrough -> write complete if committed to disk; guest no need to flush.
- None -> Equivalent to direct access to host disk. Guest needs to flush.
- Unsafe -> eq writeback but flush ignored. Performance.
- Directsync -> writethrough but without host page cache.
Safe if guest uses `commit` and `barrier` and therefore `fdatasync` syscalls on a recurring basis.
|
