qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] file-posix: Cache lseek result for data regions


From: Eric Blake
Subject: Re: [Qemu-devel] [PATCH] file-posix: Cache lseek result for data regions
Date: Fri, 25 Jan 2019 07:26:10 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 1/25/19 3:13 AM, Vladimir Sementsov-Ogievskiy wrote:

> 
> before your patch:
> ]# ./test
> Formatting 'x', fmt=raw size=1048576
> qemu-io> wrote 1048576/1048576 bytes at offset 0
> 1 MiB, 1 ops; 0.0523 sec (19.093 MiB/sec and 19.0927 ops/sec)
> qemu-io> [{ "start": 0, "length": 1048576, "depth": 0, "zero": false, "data": 
> true, "offset": 0}]
> qemu-io> handle_aiocb_write_zeroes
> wrote 102400/102400 bytes at offset 102400
> 100 KiB, 1 ops; 0.0165 sec (5.898 MiB/sec and 60.3974 ops/sec)
> qemu-io> [{ "start": 0, "length": 102400, "depth": 0, "zero": false, "data": 
> true, "offset": 0},
> { "start": 102400, "length": 102400, "depth": 0, "zero": true, "data": false, 
> "offset": 102400},
> { "start": 204800, "length": 843776, "depth": 0, "zero": false, "data": true, 
> "offset": 204800}]
> qemu-io> handle_aiocb_write_zeroes_unmap
> wrote 102400/102400 bytes at offset 512000
> 100 KiB, 1 ops; 0.0001 sec (545.566 MiB/sec and 5586.5922 ops/sec)
> qemu-io> [{ "start": 0, "length": 102400, "depth": 0, "zero": false, "data": 
> true, "offset": 0},
> { "start": 102400, "length": 102400, "depth": 0, "zero": true, "data": false, 
> "offset": 102400},
> { "start": 204800, "length": 307200, "depth": 0, "zero": false, "data": true, 
> "offset": 204800},
> { "start": 512000, "length": 102400, "depth": 0, "zero": true, "data": false, 
> "offset": 512000},
> { "start": 614400, "length": 434176, "depth": 0, "zero": false, "data": true, 
> "offset": 614400}]

Your demonstration pre-patch shows that both 'write -z' and 'write -z
-u' produced areas of the qcow2 image that were marked as known zeroes,
and claim 'data':false meaning that those two areas are sparse (that is,
it appears 'write -z' managed to unmap after all?)

> 
> 
> 
> after your patch:
> # ./test
> Formatting 'x', fmt=raw size=1048576
> qemu-io> wrote 1048576/1048576 bytes at offset 0
> 1 MiB, 1 ops; 0.0768 sec (13.019 MiB/sec and 13.0195 ops/sec)
> qemu-io> [{ "start": 0, "length": 1048576, "depth": 0, "zero": false, "data": 
> true, "offset": 0}]
> qemu-io> handle_aiocb_write_zeroes
> wrote 102400/102400 bytes at offset 102400
> 100 KiB, 1 ops; 0.0166 sec (5.883 MiB/sec and 60.2410 ops/sec)
> qemu-io> [{ "start": 0, "length": 1048576, "depth": 0, "zero": false, "data": 
> true, "offset": 0}]

So here, the cache was not invalidated, so the 'write -z' area was
temporarily reported as data...

> qemu-io> handle_aiocb_write_zeroes_unmap
> wrote 102400/102400 bytes at offset 512000
> 100 KiB, 1 ops; 0.0002 sec (469.501 MiB/sec and 4807.6923 ops/sec)
> qemu-io> [{ "start": 0, "length": 102400, "depth": 0, "zero": false, "data": 
> true, "offset": 0},
> { "start": 102400, "length": 102400, "depth": 0, "zero": true, "data": false, 
> "offset": 102400},
> { "start": 204800, "length": 307200, "depth": 0, "zero": false, "data": true, 
> "offset": 204800},
> { "start": 512000, "length": 102400, "depth": 0, "zero": true, "data": false, 
> "offset": 512000},
> { "start": 614400, "length": 434176, "depth": 0, "zero": false, "data": true, 
> "offset": 614400}]

but after the 'write -z -u' invalidated the cache, we once again see
that the 'write -z' worked.

> 
> 
> So, you've changed behavior of block_status after write_zeroes without UNMAP 
> for the worse.
> 
> Hmm, should I prepare patch for qemu-io? qemu-img map is definitely better.

qemu-io map is NOT asking the same information as qemu-img map (it's
annoying - but BOTH pieces of information are useful, and there are some
iotests that check both outputs to get a full picture of things).
qemu-img asks as much information as possible about all layers, while
qemu-io asks only abut the top layer.

That said, qemu-io is NOT baked in stone; if you want to patch it AND
fix the iotest fallout, I'm not opposed to that.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3226
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]