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

["Denis V. Lunev" <den@openvz.org>]

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 <den@openvz.org>
>> CC: Kevin Wolf <kwolf@redhat.com>
>> CC: Stefan Hajnoczi <stefanha@redhat.com>
>> ---
>>   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 :)