Re: [Qemu-devel] [PATCH] block/io.c: fix for the allocation failure

2019-08-19 Thread Eric Blake
On 8/19/19 3:53 PM, Denis V. Lunev wrote: Or even better, fix the call site of fallocate() to skip attempting an unaligned fallocate(), and just directly return ENOTSUP, rather than trying to diagnose EINVAL after the fact. >>> No way. Single ENOTSUP will turn off fallocate()

Re: [Qemu-devel] [PATCH] block/io.c: fix for the allocation failure

2019-08-19 Thread Denis V. Lunev
On 8/19/19 11:30 PM, Eric Blake wrote: > On 8/19/19 2:46 PM, Denis V. Lunev wrote: >> On 8/17/19 5:56 PM, Eric Blake wrote: >>> On 8/17/19 9:49 AM, Eric Blake wrote: >>> > This change is a regression of sorts. Now, you are unconditionally > attempting the fallback for ALL failures (such

Re: [Qemu-devel] [PATCH] block/io.c: fix for the allocation failure

2019-08-19 Thread Eric Blake
On 8/19/19 2:46 PM, Denis V. Lunev wrote: > On 8/17/19 5:56 PM, Eric Blake wrote: >> On 8/17/19 9:49 AM, Eric Blake wrote: >> This change is a regression of sorts. Now, you are unconditionally attempting the fallback for ALL failures (such as EIO) and for all drivers, even when

Re: [Qemu-devel] [PATCH] block/io.c: fix for the allocation failure

2019-08-19 Thread Denis V. Lunev
On 8/17/19 5:56 PM, Eric Blake wrote: > On 8/17/19 9:49 AM, Eric Blake wrote: > >>> This change is a regression of sorts. Now, you are unconditionally >>> attempting the fallback for ALL failures (such as EIO) and for all >>> drivers, even when that was not previously attempted and increases the

Re: [Qemu-devel] [PATCH] block/io.c: fix for the allocation failure

2019-08-17 Thread Eric Blake
On 8/17/19 9:49 AM, Eric Blake wrote: >> This change is a regression of sorts. Now, you are unconditionally >> attempting the fallback for ALL failures (such as EIO) and for all >> drivers, even when that was not previously attempted and increases the >> traffic. I think we should revert this

Re: [Qemu-devel] [PATCH] block/io.c: fix for the allocation failure

2019-08-17 Thread Eric Blake
On 8/17/19 9:42 AM, Eric Blake wrote: > On 4/5/19 9:24 AM, Andrey Shinkevich wrote: >> On a file system used by the customer, fallocate() returns an error > > Which error? Okay, I read the rest of the thread; EINVAL. But the commit message was not amended before becoming commit 118f9944. >>

Re: [Qemu-devel] [PATCH] block/io.c: fix for the allocation failure

2019-08-17 Thread Eric Blake
On 4/5/19 9:24 AM, Andrey Shinkevich wrote: > On a file system used by the customer, fallocate() returns an error Which error? > if the block is not properly aligned. So, bdrv_co_pwrite_zeroes() > fails. We can handle that case the same way as it is done for the > unsupported cases, namely, call

Re: [Qemu-devel] [PATCH] block/io.c: fix for the allocation failure

2019-04-08 Thread Andrey Shinkevich
On 08/04/2019 12:00, Stefan Hajnoczi wrote: > On Fri, Apr 05, 2019 at 05:24:04PM +0300, Andrey Shinkevich wrote: >> On a file system used by the customer, fallocate() returns an error >> if the block is not properly aligned. So, bdrv_co_pwrite_zeroes() >> fails. We can handle that case the same

Re: [Qemu-devel] [PATCH] block/io.c: fix for the allocation failure

2019-04-08 Thread Stefan Hajnoczi
On Fri, Apr 05, 2019 at 05:24:04PM +0300, Andrey Shinkevich wrote: > On a file system used by the customer, fallocate() returns an error > if the block is not properly aligned. So, bdrv_co_pwrite_zeroes() > fails. We can handle that case the same way as it is done for the > unsupported cases,

[Qemu-devel] [PATCH] block/io.c: fix for the allocation failure

2019-04-05 Thread Andrey Shinkevich
On a file system used by the customer, fallocate() returns an error if the block is not properly aligned. So, bdrv_co_pwrite_zeroes() fails. We can handle that case the same way as it is done for the unsupported cases, namely, call to bdrv_driver_pwritev() that writes zeroes to an image for the