Re: [Qemu-devel] Quick nbdkit question

[Eric Blake]

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