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
next prev parent 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).