qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Richard W.M. Jones" <rjones@redhat.com>
To: Hu Tao <hutao@cn.fujitsu.com>
Cc: Kevin Wolf <kwolf@redhat.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 v12 0/6] qcow2, raw: add preallocation=full and preallocation=falloc
Date: Mon, 25 Aug 2014 11:31:13 +0100	[thread overview]
Message-ID: <20140825103112.GR1302@redhat.com> (raw)
In-Reply-To: <20140825051830.GC25054@G08FNSTD100614.fnst.cn.fujitsu.com>

On Mon, Aug 25, 2014 at 01:18:30PM +0800, Hu Tao wrote:
> On Fri, Aug 22, 2014 at 05:00:08PM +0100, Richard W.M. Jones wrote:
> > What is proposed to be called 'preallocation=falloc' should fall back
> > to other methods (eg. writing random, writing zeroes).  It should
> > also be called something more useful like 'preallocation=best'.
> 
> What if user cares about time(writing zeroes or non-zeroes is
> time-consuming) and wants falloc only sometimes? I think this is the
> main difference between preallocation=falloc and preallocation=full.

So fallocate fails, and then what?

The user wants something which just works, not something which will
fail inexplicably.  As a rule of thumb, end users and higher layers of
the virt stack have absolutely no idea about the details of what
happens in qemu, and requiring to have this knowledge is impossible.

If it takes too long, that's a performance problem to look into --
fixed by using a filesystem that uses extents.

> > What is proposed to be called 'preallocation=full' should not write
> > just zeroes.  It needs to write random data since otherwise lower
> > layers could discard those writes and that would mean metadata
> > allocations could still take time (or fail).  It could also be called
> > something more useful, say, 'preallocation=tryveryhard'.
> 
> I agree with you on this one, but does it need to be random? does ~0 work?

As I said in the other part of this email, I don't actually think
we should implement such an option.  A simple preallocation option
that just works most of the time is fine.

However since you asked, ~0 will not work.  For a long time SANs have
been able to detect the same data in two blocks and combine them, a
process called 'deduplication'.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

  reply	other threads:[~2014-08-25 10:31 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-11  6:09 [Qemu-devel] [PATCH v12 0/6] qcow2, raw: add preallocation=full and preallocation=falloc Hu Tao
2014-07-11  6:09 ` [Qemu-devel] [PATCH v12 1/6] block: round up file size to nearest sector Hu Tao
2014-08-22 10:55   ` Kevin Wolf
2014-08-25  1:11     ` Hu Tao
2014-07-11  6:09 ` [Qemu-devel] [PATCH v12 2/6] raw, qcow2: don't convert file size to sector size Hu Tao
2014-07-11  6:10 ` [Qemu-devel] [PATCH v12 3/6] rename parse_enum_option to qapi_enum_parse and make it public Hu Tao
2014-07-11  6:10 ` [Qemu-devel] [PATCH v12 4/6] qapi: introduce PreallocMode and a new PreallocMode full Hu Tao
2014-08-22 10:57   ` Kevin Wolf
2014-08-25  1:12     ` Hu Tao
2014-07-11  6:10 ` [Qemu-devel] [PATCH v12 5/6] raw-posix: Add falloc and full preallocation option Hu Tao
2014-08-22 10:58   ` Kevin Wolf
2014-08-25  1:18     ` Hu Tao
2014-07-11  6:10 ` [Qemu-devel] [PATCH v12 6/6] qcow2: " Hu Tao
2014-07-11 21:07   ` Max Reitz
2014-08-22 11:00   ` Kevin Wolf
2014-08-25  1:36     ` Hu Tao
2014-07-28  8:48 ` [Qemu-devel] [PATCH v12 0/6] qcow2, raw: add preallocation=full and preallocation=falloc Hu Tao
2014-08-22 10:54   ` Kevin Wolf
2014-08-25  1:35     ` Hu Tao
2014-08-26 10:44       ` Stefan Hajnoczi
2014-08-28  5:04         ` Hu Tao
2014-08-22 12:25   ` Richard W.M. Jones
2014-08-22 12:36     ` Daniel P. Berrange
2014-08-22 13:13     ` Kevin Wolf
2014-08-22 13:26       ` Richard W.M. Jones
2014-08-22 14:20       ` Daniel P. Berrange
2014-08-22 15:22         ` Kevin Wolf
2014-08-22 15:34           ` Richard W.M. Jones
2014-08-22 15:39             ` Richard W.M. Jones
2014-08-22 15:53             ` Kevin Wolf
2014-08-22 16:00               ` Richard W.M. Jones
2014-08-25  5:18                 ` Hu Tao
2014-08-25 10:31                   ` Richard W.M. Jones [this message]
2014-08-25 13:44                   ` Richard W.M. Jones
2014-08-26  5:27                 ` 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=20140825103112.GR1302@redhat.com \
    --to=rjones@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).