[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [RFC PATCH v3 1/4] block: Implement bdrv_aio_pwrite

From: Stefan Hajnoczi
Subject: [Qemu-devel] Re: [RFC PATCH v3 1/4] block: Implement bdrv_aio_pwrite
Date: Thu, 2 Dec 2010 13:04:31 +0000

On Thu, Dec 2, 2010 at 12:30 PM, Kevin Wolf <address@hidden> wrote:
> Am 02.12.2010 13:07, schrieb Stefan Hajnoczi:
>> On Tue, Nov 30, 2010 at 12:48 PM, Kevin Wolf <address@hidden> wrote:
>> I guess what I'm saying is that this function should only be used when
>> you really need rmw (in many cases with image metadata it can be
>> avoided because you have enough metadata cached in memory to do full
>> sector writes).  If it turns out we don't need rmw then we can
>> eliminate this function.
> Maybe what we really should do is completely change the block layer
> functions to use bytes as their unit and do any RMW in posix-aio-compat
> and linux-aio. Other backends don't need it and without O_DIRECT we
> don't even need to do it with files.

Yeah that sounds like something worth exploring more.  Perhaps
together with some input from Christoph on moving QEMU to the native
block size (e.g. 4k on some devices).

>>> +BlockDriverAIOCB *bdrv_aio_pwrite(BlockDriverState *bs, int64_t offset,
>>> +    void* buf, size_t bytes, BlockDriverCompletionFunc *cb, void *opaque)
>>> +{
>>> +    PwriteAIOCB *acb;
>>> +
>>> +    acb = qemu_aio_get(&blkqueue_aio_pool, bs, cb, opaque);
>>> +    acb->state      = 0;
>>> +    acb->offset     = offset;
>>> +    acb->buf        = buf;
>>> +    acb->bytes      = bytes;
>>> +    acb->tmp_buf    = NULL;
>>> +
>>> +    bdrv_aio_pwrite_cb(acb, 0);
>> We're missing the usual !bs->drv, bs->read_only, bdrv_check_request()
>> checks here.  Are we okay to wait until calling
>> bdrv_aio_readv/bdrv_aio_writev for these checks?
> I think we are, but if you prefer, I can copy them here.

No, I just wanted to make sure you took them into account.  In theory
those error cases won't affect your code and it's fine to wait for
bdrv_aio_readv/bdrv_aio_writev to catch them.  I haven't thought
through the cases in detail though.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]