On 8/8/19 2:41 AM, Richard W.M. Jones wrote: > On Wed, Aug 07, 2019 at 02:30:18PM -0700, ivo welch wrote: >> hi richard---please forgive us. another quickie. we created an nbd >> device. just a block device...no partitions, etc. in the guest vm, we >> wrote a short C program that writes one sector (open file, fseek, fwrite, >> close file) and then does it again. all is working just fine. the host >> console (filter) prints out the write requests, as it should. (we added >> some more print code.) >> >> but we are confused about that after the first [but not the second] write, >> we see about 30 (4096b) sector reads, starting from 4096, 12288, ... . >> (the file below has both the C code and the nbdkit messages.) > > I guess it's happening because of readahead in the qemu NBD driver, or > generally in the QEMU block layer. Eric or Kevin will probably have a > better idea.
More likely, it's happening in the guest OS. The kernel probes a lot of sectors when first mounting block storage, to determine what lives on that storage. Rich even has a graphical demonstration of that probing in his FOSDEM 2019 presentation. https://rwmj.wordpress.com/2019/02/04/video-take-your-loop-mounts-to-the-next-level-with-nbdkit/ around the 21:20 mark. > >> there is no file system layer here, just an nbdkit block device. what is >> reading sectors here? is it the stdio.h library in the guest, something >> magic about access into an unformatted block device in the guest VM linux, >> or nbdkit itself?! does this sound familiar? In order to determine if storage is formatted or not, the guest VM Linux kernel reads a lot of sectors. Qemu is not doing readahead, so much as faithfully reproducing the read requests from the guest. There are places where qemu tries to consolidate consecutive actions from the guest into one larger action to the storage, and we also have ideas about adding a caching filter which can perform readahead and such for performance, but I don't think they can be universally enabled in qemu without penalizing some users, so it should be obvious when you are opting in to those sorts of qemu features. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature