Re: [Qemu-devel] [PATCH] qemu-img: Do not truncate before preallocation

[Kevin Wolf <kwolf@redhat.com>]

Am 03.02.2017 um 20:50 hat Nir Soffer geschrieben:
> When using file system that does not support fallocate() (e.g. NFS <
> 4.2), truncating the file only when preallocation=OFF speeds up creating
> raw file.
> 
> Here is example run, tested on Fedora 24 machine, creating raw file on
> NFS version 3 server.
> 
> $ time ./qemu-img-master create -f raw -o preallocation=falloc mnt/test 1g
> Formatting 'mnt/test', fmt=raw size=1073741824 preallocation=falloc
> 
> real	0m21.185s
> user	0m0.022s
> sys	0m0.574s
> 
> $ time ./qemu-img-fix create -f raw -o preallocation=falloc mnt/test 1g
> Formatting 'mnt/test', fmt=raw size=1073741824 preallocation=falloc
> 
> real	0m11.601s
> user	0m0.016s
> sys	0m0.525s
> 
> $ time dd if=/dev/zero of=mnt/test bs=1M count=1024 oflag=direct
> 1024+0 records in
> 1024+0 records out
> 1073741824 bytes (1.1 GB, 1.0 GiB) copied, 15.6627 s, 68.6 MB/s
> 
> real	0m16.104s
> user	0m0.009s
> sys	0m0.220s
> 
> Running with strace we can see that without this change we do one
> pread() and one pwrite() for each block. With this change, we do only
> one pwrite() per block.
> 
> $ strace ./qemu-img-master create -f raw -o preallocation=falloc mnt/test 8192
> ...
> pread64(9, "\0", 1, 4095)               = 1
> pwrite64(9, "\0", 1, 4095)              = 1
> pread64(9, "\0", 1, 8191)               = 1
> pwrite64(9, "\0", 1, 8191)              = 1
> 
> $ strace ./qemu-img-fix create -f raw -o preallocation=falloc mnt/test 8192
> ...
> pwrite64(9, "\0", 1, 4095)              = 1
> pwrite64(9, "\0", 1, 8191)              = 1
> 
> This happens because posix_fallocate is checking if each block is
> allocated before writing a byte to the block, and when truncating the
> file before preallocation, all blocks are unallocated.
> 
> Signed-off-by: Nir Soffer <nirsof@gmail.com>

Thanks, applied to the block branch.

I'm not completely sure if doing an ftruncate() first couldn't improve
PREALLOC_MODE_FULL somewhat in some cases, but I agree that the patch
should still result in correct images.

KEvin