qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 18/19] block/parallels: add prealloc-mode and pr


From: Denis V. Lunev
Subject: Re: [Qemu-devel] [PATCH 18/19] block/parallels: add prealloc-mode and prealloc-size open paramemets
Date: Wed, 14 Jan 2015 17:31:20 +0300
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0

On 14/01/15 17:26, Roman Kagan wrote:
On Tue, Dec 30, 2014 at 01:07:11PM +0300, Denis V. Lunev wrote:
This is preparational commit for tweaks in Parallels image expansion.
The idea is that enlarge via truncate by one data block is slow. It
would be much better to use fallocate via bdrv_write_zeroes and
expand by some significant amount at once.

This patch just adds proper parameters into BDRVParallelsState and
performs options parsing in parallels_open.

Signed-off-by: Denis V. Lunev <address@hidden>
CC: Kevin Wolf <address@hidden>
CC: Stefan Hajnoczi <address@hidden>
---
  block/parallels.c | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 72 insertions(+)

diff --git a/block/parallels.c b/block/parallels.c
index 18b9267..12a9cea 100644
--- a/block/parallels.c
+++ b/block/parallels.c
@@ -30,6 +30,7 @@
  #include "qemu-common.h"
  #include "block/block_int.h"
  #include "qemu/module.h"
+#include "qapi/util.h"
/**************************************************************/ @@ -54,6 +55,20 @@ typedef struct ParallelsHeader {
      char padding[12];
  } QEMU_PACKED ParallelsHeader;
+
+typedef enum ParallelsPreallocMode {
+    PRL_PREALLOC_MODE_FALLOCATE = 0,
+    PRL_PREALLOC_MODE_TRUNCATE = 1,
+    PRL_PREALLOC_MODE_MAX = 2,
+} ParallelsPreallocMode;
+
+static const char *prealloc_mode_lookup[] = {
+    "falloc",
+    "truncate",
+    NULL,
There is already generic "preallocaton" option, BLOCK_OPT_PREALLOC,
which is handled by qcow2 and raw-posix.  It means slightly different
thing: the *whole* image is preallocated using the method specified.

I think it would make sense to consolidate that option with this new
batched allocation in the generic block code.  I guess qcow2 and
raw-posix would benefit from it, too.

At any rate I think it's a matter for a separate patchset.

Roman.
it is too early :) I think that I should provide the rationale for
the preallocation in general. I am working on this with CEPH :)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]