qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert


From: Max Reitz
Subject: Re: [Qemu-block] [Qemu-devel] [RFC] qemu-img: Drop BLK_ZERO from convert
Date: Wed, 28 Feb 2018 19:08:09 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 2018-02-27 17:17, Stefan Hajnoczi wrote:
> On Mon, Feb 26, 2018 at 06:03:13PM +0100, Max Reitz wrote:
>> There are filesystems (among which is tmpfs) that have a hard time
>> reporting allocation status.  That is definitely a bug in them.
>>
>> However, there is no good reason why qemu-img convert should query the
>> allocation status in the first place.  It does zero detection by itself
>> anyway, so we can detect unallocated areas ourselves.
>>
>> Furthermore, if a filesystem driver has any sense, reading unallocated
>> data should take just as much time as lseek(SEEK_DATA) + memset().  So
>> the only overhead we introduce by dropping the manual lseek() call is a
>> memset() in the driver and a buffer_is_zero() in qemu-img, both of which
>> should be relatively quick.
> 
> This makes sense.  Which file systems did you test this patch on?

On tmpfs and xfs, so far.

> XFS, ext4, and tmpfs would be a good minimal test set to prove the
> patch.  Perhaps with two input files:
> 1. A file that is mostly filled with data.
> 2. A file that is only sparsely populated with data.

And probably with vmdk, which (by default) forbids querying any areas
larger than 64 kB.

> The time taken should be comparable with the time before this patch.

Yep, I'll do some benchmarks.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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