Open wkozaczuk opened 5 months ago
As Jan Braunwarth eloquently explains in his bachelor thesis, the OSv block cache is very inefficient:
Interesting, can you please post here a link to this bachelor thesis?
Let me send it to you! It is in german but you can easily google-translate.
As Jan Braunwarth eloquently explains in his bachelor thesis, the OSv block cache is very inefficient:
"OSv also has a cache that should increase I/O performance, but it is very inefficient and, as you can see in Figure 4.8, does not lead to an increase but rather a dramatic drop. If you look at how the block cache works, it quickly becomes clear why this is. Each I/O is initially divided by the cache into 512 byte blocks. Then, when a read request is made, each block is checked to see whether it is already in the cache and, if so, copied directly from there to the target address. Since the RAM can answer the request much faster, this administrative effort is worth it. The problem is what happens when the block is not yet in the cache.
For example, if an application wants to read a 1 MiB file that is not yet in the cache, the request is divided into 2048 I/Os, each 512B in size. These 2048 requests are then all processed sequentially and also copied from the block cache to the target address. The measured IOPS are therefore significantly lower than the number of SQEs that were processed by the NVMe."
It must be noted, however, that most applications will not be affected by it as they will go through the VFS layer. The filesystems drivers in OSv (ZFS, RoFS, and recently EXT4) bypass the block cache and call
devops->strategy()
directlyTo reproduce this problem, one can use the fio app setup to read from disk directly (as bypasses the file system):
There are at least two options to fix this moderately important issue:
devops->strategy()
use it as well (more difficult)bread
andbwrite
with code similar to what thestrategy
functions do like in this proposed patch (easy):