From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XLrYe-0002ux-WF for qemu-devel@nongnu.org; Mon, 25 Aug 2014 06:31:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XLrYZ-0007UU-4A for qemu-devel@nongnu.org; Mon, 25 Aug 2014 06:31:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35202) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XLrYY-0007UJ-T2 for qemu-devel@nongnu.org; Mon, 25 Aug 2014 06:31:23 -0400 Date: Mon, 25 Aug 2014 11:31:13 +0100 From: "Richard W.M. Jones" Message-ID: <20140825103112.GR1302@redhat.com> References: <20140728084846.GH31917@G08FNSTD100614.fnst.cn.fujitsu.com> <20140822122556.GJ14001@redhat.com> <20140822131331.GN32377@noname.redhat.com> <20140822142016.GN8447@redhat.com> <20140822152233.GP32377@noname.redhat.com> <20140822153440.GK1302@redhat.com> <20140822155322.GQ32377@noname.redhat.com> <20140822160008.GL1302@redhat.com> <20140825051830.GC25054@G08FNSTD100614.fnst.cn.fujitsu.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140825051830.GC25054@G08FNSTD100614.fnst.cn.fujitsu.com> Subject: Re: [Qemu-devel] [PATCH v12 0/6] qcow2, raw: add preallocation=full and preallocation=falloc List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hu Tao Cc: Kevin Wolf , qemu-devel@nongnu.org, Max Reitz , Stefan Hajnoczi , Yasunori Goto 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