Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O

[Anthony Liguori <anthony@codemonkey.ws>]

Gerd Hoffmann wrote:
> Anthony Liguori wrote:
>   
>>> IMHO it would be a much better idea to kill the aio interface altogether
>>> and instead make the block drivers reentrant.  Then you can use
>>> (multiple) posix threads to run the I/O async if you want.
>>>       
>> Threads are a poor substitute for a proper AIO interface.  linux-aio
>> gives you everything you could possibly want in an interface since it
>> allows you to submit multiple vectored operations in a single syscall,
>> use an fd to signal request completion, complete multiple requests in a
>> single syscall, and inject barriers via fdsync.
>>     
>
> I still think implementing async i/o at block driver level is the wrong
> thing to do.  You'll end up reinventing the wheel over and over again
> and add complexity to the block drivers which simply doesn't belong
> there (or not supporting async I/O for most file formats).  Just look at
> the insane file size of the block driver for the simplest possible disk
> format: block-raw.c.  It will become even worse when adding a
> linux-specific aio variant.
>
> In contrast:  Making the disk drivers reentrant should be easy for most
> of them.  For the raw driver it should be just using pread/pwrite
> syscalls instead of lseek + read/write (also saves a syscall along the
> way, yea!).  Others probably need an additional lock for metadata
> updates.  With that in place you can easily implement async I/O via
> threads one layer above, and only once, in block.c.
>   

I really want to use readv/writev though.  With virtio, we get a 
scatter/gather list for each IO request.

Once I post the virtio-blk driver, I'll follow up a little later with 
some refactoring of the block device layers.  I think it can be made 
much simpler while still remaining asynchronous.

> IMHO the only alternative to that scheme would be to turn the block
> drivers in some kind of remapping drivers for the various file formats
> which don't actually perform the I/O.  Then you can handle the actual
> I/O in a generic way using whatever API is available, be it posix-aio,
> linux-aio or slow-sync-io.
>   

That's part of my plan.

Regards,

Anthony Liguori

> cheers,
>   Gerd
>
>
>
>