[liburing,0/4] spec: rpmlint fixes in preparation for Fedora packaging

Message

Stefan Hajnoczi Aug. 3, 2019, 8:45 a.m. UTC

This series addresses the remaining rpm issues that I'm aware of.

Jens: Once the patches are merged and you publish a 0.1 release tag I could
roll the first liburing rpm for Fedora.  liburing itself is in good shape for
wider consumption but maybe it makes sense to wait for kernel issues to settle.
There are qemu-iotests failures that are probably kernel bugs (hopefully known
ones!) and will be investigated soon.

Stefan Hajnoczi (4):
  COPYING: update to latest LGPL v2.1 text
  spec: use Fedora "LGPLv2+" license identifier
  spec: add URL tag
  spec: fix <liburing/*.h> permissions

 COPYING       | 79 +++++++++++++++++++++------------------------------
 liburing.spec |  5 ++--
 2 files changed, 36 insertions(+), 48 deletions(-)

Comments

Jens Axboe Aug. 3, 2019, 2:25 p.m. UTC | #1

On 8/3/19 2:45 AM, Stefan Hajnoczi wrote:
> This series addresses the remaining rpm issues that I'm aware of.
> 
> Jens: Once the patches are merged and you publish a 0.1 release tag I could
> roll the first liburing rpm for Fedora.  liburing itself is in good shape for
> wider consumption but maybe it makes sense to wait for kernel issues to settle.
> There are qemu-iotests failures that are probably kernel bugs (hopefully known
> ones!) and will be investigated soon.

Applied all 4, thanks.

Any pointers to the qemu-iotests failures?

Jens Axboe Aug. 8, 2019, 4:13 p.m. UTC | #2

On 8/8/19 3:32 AM, Stefan Hajnoczi wrote:
> On Mon, Aug 05, 2019 at 05:14:11PM +0100, Stefan Hajnoczi wrote:
> 
> Sorry Jens, I had your old email address.  Resent.
> 
>> Hi Jens,
>> I've minimized one of the qemu-iotests failures and it looks like a
>> kernel bug.  io_uring completes a request with EAGAIN on an O_DIRECT
>> file with Linux 5.3-rc1 on XFS + dm-thin + dm-crypt:
>>
>>    $ qemu-img create -f raw t.img 6G
>>    $ qemu-io -f raw -n -i io_uring -c "aio_write 0 1M" -c "aio_write 512 1M" t.img
>>    $ qemu-io -f raw -n -i io_uring -c "aio_write $((1 * 1024 * 1024)) 1M" -c "aio_write $((1 * 1024 * 1024 + 512)) 1M" t.img
>>    Formatting 'tests/qemu-iotests/scratch/t.img', fmt=raw size=6442450944
>>    wrote 1048576/1048576 bytes at offset 0
>>    1 MiB, 1 ops; 00.01 sec (128.598 MiB/sec and 128.5985 ops/sec)
>>    wrote 1048576/1048576 bytes at offset 512
>>    1 MiB, 1 ops; 00.00 sec (201.017 MiB/sec and 201.0169 ops/sec)
>>    aio_write failed: Resource temporarily unavailable
>>    wrote 1048576/1048576 bytes at offset 1049088
>>    1 MiB, 1 ops; 00.00 sec (391.620 MiB/sec and 391.6198 ops/sec)
>>
>> The third write request should not fail with EAGAIN ("Resource
>> temporarily available").  I think device-mapper is returning EAGAIN at
>> some point but I haven't gotten to the bottom of this yet.
>>
>> Interestingly it only happens when qemu-img create is run before the
>> test to create a new file.  Rerun qemu-io on an existing raw image file
>> and it succeeds.  This could be because the failing request is XFS a
>> metadata I/O request that only happens when writing the file for the
>> first time.

It's due to how XFS handles (or doesn't handle) REQ_NOWAIT. I've got
a patch for this that needs some testing, but I probably won't get to
this until Monday, currently out on vacation until Sunday.