On Sun, 2019-08-25 at 22:51 +0300, Nir Soffer wrote: > On Sun, Aug 25, 2019 at 10:44 AM Maxim Levitsky <mlevi...@redhat.com> wrote: > > On Sat, 2019-08-17 at 00:21 +0300, Nir Soffer wrote: > > > When creating an image with preallocation "off" or "falloc", the first > > > block of the image is typically not allocated. When using Gluster > > > storage backed by XFS filesystem, reading this block using direct I/O > > > succeeds regardless of request length, fooling alignment detection. > > > > > > In this case we fallback to a safe value (4096) instead of the optimal > > > value (512), which may lead to unneeded data copying when aligning > > > requests. Allocating the first block avoids the fallback. > > > > > > When using preallocation=off, we always allocate at least one filesystem > > > block: > > > > > > $ ./qemu-img create -f raw test.raw 1g > > > Formatting 'test.raw', fmt=raw size=1073741824 > > > > > > $ ls -lhs test.raw > > > 4.0K -rw-r--r--. 1 nsoffer nsoffer 1.0G Aug 16 23:48 test.raw > > > > Are you sure about this? > > This is the new behaviour with this change... > > > [mlevitsk@maximlenovopc ~/work/test_area/posix-file 0]$ qemu-img create -f > > raw test.raw 1g -o preallocation=off > > Formatting 'test.raw', fmt=raw size=1073741824 preallocation=off > > [mlevitsk@maximlenovopc ~/work/test_area/posix-file 0]$ls -lhs ./test.raw > > 0 -rw-r--r--. 1 mlevitsk mlevitsk 1.0G Aug 25 10:38 ./test.raw > > > > ext4, tested on qemu-4.0.0 and qemu git master. > > And this is the old behavior. I guess the commit message does not make it > clear.
Ah, thanks! > > From what I remember, the only case when posix-raw touches the first block > > is to zero it out > > when running on top of kernel block device, to erase whatever header might > > be there, and this > > is also kind of a backward compat hack which might be one day removed. > > This change is only for file, on block storage we use BLKSSZGET. > > > [...] > > > > Best regards, > > Maxim Levitsky > > > > Best regards, Maxim Levitsky