qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rjones@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Fam Zheng <famz@redhat.com>, Hu Tao <hutao@cn.fujitsu.com>,
	qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Yasunori Goto <y-goto@jp.fujitsu.com>
Subject: Re: [Qemu-devel] [PATCH v13 5/6] raw-posix: Add full preallocation option
Date: Thu, 4 Sep 2014 14:43:07 +0100	[thread overview]
Message-ID: <20140904134307.GD1302@redhat.com> (raw)
In-Reply-To: <20140904131751.GK3897@noname.str.redhat.com>

On Thu, Sep 04, 2014 at 03:17:51PM +0200, Kevin Wolf wrote:
> Am 04.09.2014 um 15:07 hat Richard W.M. Jones geschrieben:
> > On Thu, Sep 04, 2014 at 02:52:57PM +0200, Kevin Wolf wrote:
> > > Am 04.09.2014 um 14:45 hat Richard W.M. Jones geschrieben:
> > > > On Thu, Sep 04, 2014 at 02:35:22PM +0200, Kevin Wolf wrote:
> > > > > Please change the code to always write zeros for FULL,
> > > > 
> > > > How is this useful for anyone?  You don't know if the underlying SAN
> > > > is going to detect these zeroes or combine these blocks together.
> > > > It's just slow for no reason.
> > > 
> > > It's slow for the reason that the user has requested it. Do you doubt
> > > that users can know what their backend is doing? Why are you insisting
> > > on providing only the functionality that you personally need?
> > 
> > I'm not!  I'm trying to make sure we don't end up with a qemu
> > interface which is useless for higher layers.  You're proposing
> > preallocation=full which will be slow but not actually give any
> > guarantees, or preallocation=meta which is going to be fast but may
> > not work, and I'm saying that's a dumb interface that's not useful.
> 
> So what you propose is an interface that combines both and may
> unpredictably be slow or fast, and doesn't give any guarantees either.
> Why would this be any better?
> 
> What is your specific use case of full preallocation that wants zero
> writing, but only implicitly as a fallback? My expectation is that most
> users want cheap preallocation if it's available, but don't bother to
> write many gigabytes if it isn't.

Stepping back, I think what we have are two general approaches:

 - do the exact thing I want

 - do the best effort you can

virt-manager, virt-install, virt-clone, libvirt, libguestfs, all
currently do preallocation with fallback to writing data (via
hand-written code).  The reason is that customers using simple disks
(not SANs etc) just want to be sure they're not going to run out of
space during OS installation.  For the vast majority of users,
posix_fallocate makes this fast, but people using ext2 or *BSD get the
slow-but-safe path.

Now it may be that some qemu users are going to want a very exact
preallocation mode, but that doesn't mean we can't have
preallocation=besteffort too.

And it's not just here.  qemu has other places where we'd like "do the
best thing", not "do the exact thing" ... off the top of my head:
selecting -cpu, discard support, O_DIRECT.  Libguestfs has to go
through hoops in these areas, often involving very hairy workarounds
which reduce reliability.  I'm not saying that more exact options
aren't also welcome, but doing the best effort is very useful too.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

  reply	other threads:[~2014-09-04 13:43 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-29  8:33 [Qemu-devel] [PATCH v13 0/6] qcow2, raw: add preallocation=full Hu Tao
2014-08-29  8:33 ` [Qemu-devel] [PATCH v13 1/6] block: round up file size to nearest sector Hu Tao
2014-08-29 12:50   ` Eric Blake
2014-09-04  9:33     ` Kevin Wolf
2014-09-02 21:21   ` Max Reitz
2014-09-04  9:43   ` Kevin Wolf
2014-08-29  8:33 ` [Qemu-devel] [PATCH v13 2/6] block: don't convert file size to sector size Hu Tao
2014-09-02 21:24   ` Max Reitz
2014-09-04  9:57   ` Kevin Wolf
2014-09-05  9:07     ` Hu Tao
2014-08-29  8:33 ` [Qemu-devel] [PATCH v13 3/6] rename parse_enum_option to qapi_enum_parse and make it public Hu Tao
2014-09-02 21:27   ` Max Reitz
2014-09-03  1:30     ` Hu Tao
2014-09-04 10:03   ` Kevin Wolf
2014-08-29  8:33 ` [Qemu-devel] [PATCH v13 4/6] qapi: introduce PreallocMode and a new PreallocMode full Hu Tao
2014-09-02 21:32   ` Max Reitz
2014-09-03  1:31     ` Hu Tao
2014-09-02 21:51   ` Eric Blake
2014-09-03  1:35     ` Hu Tao
2014-09-04 12:17   ` Kevin Wolf
2014-08-29  8:33 ` [Qemu-devel] [PATCH v13 5/6] raw-posix: Add full preallocation option Hu Tao
2014-08-29  8:48   ` Richard W.M. Jones
2014-09-03  1:26     ` Hu Tao
2014-09-04  8:32     ` Hu Tao
2014-09-02 21:45   ` Max Reitz
2014-09-03  1:55     ` Hu Tao
2014-09-04 12:35   ` Kevin Wolf
2014-09-04 12:45     ` Richard W.M. Jones
2014-09-04 12:52       ` Kevin Wolf
2014-09-04 13:07         ` Richard W.M. Jones
2014-09-04 13:13           ` Daniel P. Berrange
2014-09-04 13:17           ` Kevin Wolf
2014-09-04 13:43             ` Richard W.M. Jones [this message]
2014-09-04 15:23               ` Kevin Wolf
2014-09-04 15:33                 ` Richard W.M. Jones
2014-08-29  8:33 ` [Qemu-devel] [PATCH v13 6/6] qcow2: " Hu Tao
2014-09-02 21:55   ` Max Reitz
2014-09-04 13:09   ` Kevin Wolf
2014-09-09  3:23     ` Hu Tao

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=20140904134307.GD1302@redhat.com \
    --to=rjones@redhat.com \
    --cc=famz@redhat.com \
    --cc=hutao@cn.fujitsu.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    --cc=y-goto@jp.fujitsu.com \
    /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).