qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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

      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).