From: Eric Blake <eblake@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>, lampahome <pahome.chen@mirlab.org>
Cc: QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] How to discard one range which overlap with backing file and its children img?
Date: Tue, 7 Aug 2018 09:02:24 -0500 [thread overview]
Message-ID: <9b41f597-7d7b-8c19-51ee-274d5312395e@redhat.com> (raw)
In-Reply-To: <20180807123431.GB4499@localhost.localdomain>
On 08/07/2018 07:34 AM, Kevin Wolf wrote:
> Am 07.08.2018 um 09:06 hat lampahome geschrieben:
>> I have image A & B, and A is backing file of B.
>>
>> After I mount A to /dev/nbd0 and I write from position 0~999 in nbd0.
>>
>> Then create B and set A as backing file of B.
>>
>> I mount B on /dev/nbd1 and I can saw the data from pos:0~999 because A is
>> B's backing file. That's reasonable.
>>
>>
>> But I want to discard range 0~500 in B. I expect there's no data in 0~500
>> after discard and re-mount B next time.
>>
>> But the data is still in A.
>>
>> How can I discard range 0~500?
>
> Note that discard simply means that you don't care about the content any
> more. This doesn't guarantee that the old data can't be read any more.
> If you want to make the data invisible, you need a zero write operation
> instead. For a Linux guest, have a look at the "fallocate -z" command
> line tool.
What's more, once you make A the backing file to B, then all actions you
perform through qemu operate only on B (A is treated as read-only). So,
writing zeroes (or discarding) changes the contents of B, but does NOT
change the content of A.
Furthermore, both discard and write zeroes tend to have alignment
constraints. If you are actually working on bytes 0-999 (which is
unaligned to sector boundaries of 512, let alone qcow2 cluster
boundaries that default to 64k but can be even larger), the discard is
likely to be a no-op (since discard tends to be a no-op if it does not
meet larger alignment boundaries), while the write zeroes will work but
will result in a slower read-modify-write if it is targetting a block
device. If you are instead working on sectors 0-999 (bytes 0-511999),
you have more of a chance of seeing discard in action, as well as write
zeroes being more efficient.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
prev parent reply other threads:[~2018-08-07 14:02 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-07 7:06 [Qemu-devel] How to discard one range which overlap with backing file and its children img? lampahome
2018-08-07 12:34 ` Kevin Wolf
2018-08-07 14:02 ` Eric Blake [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b41f597-7d7b-8c19-51ee-274d5312395e@redhat.com \
--to=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=pahome.chen@mirlab.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).