All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Lieven <pl@kamp.de>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>, Fam Zheng <famz@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCHv2] block: add native support for NFS
Date: Fri, 20 Dec 2013 15:07:10 +0100	[thread overview]
Message-ID: <52B44F0E.5070403@kamp.de> (raw)
In-Reply-To: <CAJSP0QWzYbmNf5EuORCG42atRt1iMh4p=izNyOMZj8DYca3jcA@mail.gmail.com>

On 20.12.2013 14:57, Stefan Hajnoczi wrote:
> On Fri, Dec 20, 2013 at 1:53 PM, Peter Lieven <pl@kamp.de> wrote:
>> On 20.12.2013 13:19, Stefan Hajnoczi wrote:
>>> On Fri, Dec 20, 2013 at 10:48:41AM +0100, Peter Lieven wrote:
>>>> On 17.12.2013 17:47, Stefan Hajnoczi wrote:
>>>>> On Tue, Dec 17, 2013 at 10:15:25AM +0100, Peter Lieven wrote:
>>>>>> +    /* set to -ENOTSUP since bdrv_allocated_file_size is only used
>>>>>> +     * in qemu-img open. So we can use the cached value for allocate
>>>>>> +     * filesize obtained from fstat at open time */
>>>>>> +    client->allocated_file_size = -ENOTSUP;
>>>>> Can you implement this fully?  By stubbing it out like this we won't be
>>>>> able to call get_allocated_file_size() at runtime in the future without
>>>>> updating the nfs block driver code.  It's just an fstat call, shouldn't
>>>>> be too hard to implement properly :).
>>>> It seems I have to leave it as is currently. bdrv_get_allocated_file_size
>>>> is not in a coroutine context. I get coroutine yields to no one.
>>> Create a coroutine and pump the event loop until it has reached
>>> completion:
>>>
>>> co = qemu_coroutine_create(my_coroutine_fn, ...);
>>> qemu_coroutine_enter(co, foo);
>>> while (!complete) {
>>>       qemu_aio_wait();
>>> }
>>>
>>> See block.c for similar examples.
>> Wouldn't it make sense to make this modification to
>> bdrv_get_allocated_file_size in
>> block.c rather than in client/nfs.c and in the future potentially other
>> drivers?
>>
>> If yes, I would ask you to take v3 of the NFS protocol patch and I promise
>> to send
>> a follow up early next year to make this modification to block.c and change
>> block/nfs.c
>> and other implementations to be a coroutine_fn.
> .bdrv_get_allocated_file_size() implementations in other block drivers
> are synchronous.  Making the block driver interface use coroutines
> would be wrong unless all the block drivers were updated to use
> coroutines too.
I can do that. I think its not too complicated because all those
implementations do not rely on callbacks. It should be possible
to just rename the existing implemenations to lets say
.bdrv_co_get_allocated_file_size and call them inside a coroutine.
>
> Can you just call nfs_fstat() (the sync libnfs interface)?
I can only do that if its guaranteed that no other requests are in flight
otherwise it will mess up.

Peter

  reply	other threads:[~2013-12-20 14:06 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-17  9:15 [Qemu-devel] [PATCHv2] block: add native support for NFS Peter Lieven
2013-12-17 16:47 ` Stefan Hajnoczi
2013-12-17 17:03   ` Peter Lieven
2013-12-17 17:13     ` ronnie sahlberg
2013-12-17 22:36       ` Peter Lieven
2013-12-17 22:44         ` Eric Blake
2013-12-17 22:51         ` ronnie sahlberg
2013-12-17 22:56           ` Peter Lieven
2013-12-17 17:28     ` ronnie sahlberg
2013-12-17 23:00       ` Peter Lieven
2013-12-20  9:48   ` Peter Lieven
2013-12-20 12:19     ` Stefan Hajnoczi
2013-12-20 12:53       ` Peter Lieven
2013-12-20 13:57         ` Stefan Hajnoczi
2013-12-20 14:07           ` Peter Lieven [this message]
2013-12-20 14:38             ` Stefan Hajnoczi
2013-12-20 14:43               ` Peter Lieven
2013-12-20 15:03                 ` ronnie sahlberg
2013-12-20 15:30                 ` Stefan Hajnoczi
2013-12-20 15:49                   ` Peter Lieven
2013-12-20 15:54                     ` Stefan Hajnoczi
2013-12-20 15:57                       ` Peter Lieven
2013-12-20 16:27                         ` Stefan Hajnoczi
2014-01-03 10:35                           ` Peter Lieven
2013-12-17 16:53 ` ronnie sahlberg
2013-12-17 22:57   ` Peter Lieven
2013-12-17 17:32 ` Daniel P. Berrange
2013-12-17 23:03   ` Peter Lieven
2013-12-18  9:30     ` Daniel P. Berrange
2013-12-18 10:00     ` Orit Wasserman
2013-12-18 10:18       ` Daniel P. Berrange
2013-12-18 10:24         ` Orit Wasserman
2013-12-18 10:38           ` Paolo Bonzini
2013-12-18 17:21             ` Peter Lieven
2013-12-19 14:31               ` Paolo Bonzini
2013-12-18 11:11       ` Peter Lieven
2013-12-18 11:23         ` Orit Wasserman
2013-12-18 14:42       ` ronnie sahlberg
2013-12-18 16:59         ` Peter Lieven
2013-12-18 17:33           ` ronnie sahlberg
2013-12-18 17:42             ` Peter Lieven
2013-12-18 17:50               ` ronnie sahlberg
2013-12-18 17:55                 ` Peter Lieven

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52B44F0E.5070403@kamp.de \
    --to=pl@kamp.de \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.