Am 16.02.2017 um 19:23 hat Nir Soffer geschrieben: > On Thu, Feb 16, 2017 at 7:52 PM, Kevin Wolf <kw...@redhat.com> wrote: > > 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 <nir...@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. > > Good point, I'll do some tests with full mode to check this. > > Do you know which cases can benefit from ftruncate() before full > preallocation?
Knowing the final size from the beginning could allow the file system driver to do less allocations and possibly avoid fragmentation of the file. I'm not sure if that's easily measurable, though. I'd also expect that with XFS, you'll see no or less preallocation. 'du' often shows values much larger than the actual image size on XFS because the file was growing a lot, so without having the actual size, XFS takes a guess and does some generous preallocation. Kevin
