Hi Pierre!
I see your point about Copy On Write, but in this scenario most of the
data is only written once and read many times. I hoped bcache to perform
better as a read cache. I´m afraid that bcache is only caching written
(new and modified) blocks, not blocks already in backing device but not
in cache device. Cache device was attached with most of data already
resting on backing device.
What other setup would you say to be an optimal configuration to speed
up VMs I/O using qcow2 files?
Thank you and regards
El 04/06/2021 a las 14:00, Pierre Juhen escribió:
Hi !
COW from qcow2 means Copy On Write.
It means that a new block is written for each modification on an
existing block.
Therefore, a "living" block is read only once, and the statistics are
not favorable keep the blocks in the cache.
Only the "static" files (OS and frequently used program) benefit from
the cache.
So I think that qcow2 and bcache might not be a optimal configuration.
Any complement on this quick analysis ?
Regards,
Le 04/06/2021 à 13:07, Santiago Castillo Oli a écrit :
Hi all!
I'm using bcache and I think I have a rather low hit ratio and cache
occupation.
My setup is:
- Cache device: 82 GiB partition on a SSD drive. Bucket size=4M. The
partition is aligned on a Gigabyte boundary.
- Backing device: 3.6 TiB partition on a HDD drive. There is 732 GiB
of data usage on this partition. This 732 GiB are used by 9 qcow2
files assigned to 3 VMs running on the host.
- Neither the SDD nor HDD drives have another partitions in use.
- After 24 hours of use, according to priority_stats the cache is 75%
Unused (63 GiB Unused - 19 GiB used), but...
- ... according to "smartctl -a" in those 24 hours "Writes to Flash"
has increased in 160 GiB and "GB written from host" has increased in
90 GiB
- cache_hit_ratio is 10 %
- I'm using maximum bucket size (4M) trying to minimize write
amplification. With this bucket size, "Writes to Flash" (160) to "GB
written from host"(90) ratio is 1,78. Previously, some days ago, I
was using default bucket size. The write amplification ratio then was
2,01.
- Isn't the cache_hit_ratio (10%) a bit low?
- Is it normal that, after 24 hours running, the cache occupation is
that low (82-63 = 19GiB, 25%) when the host has written 90 GiB to
the cache device in the same period? I don´t understand why 90 GiB of
data has been written to fill 19 GiB of cache.
Any ideas?
Thank you and regards.
--
___________________________________________________________
