From: Max Reitz <mreitz@redhat.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Josh Durgin <jdurgin@redhat.com>,
Jason Dillaman <jdillama@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v3] block/rbd: increase dynamically the image size
Date: Tue, 25 Jun 2019 17:48:39 +0200 [thread overview]
Message-ID: <14d11ff9-b96b-47d0-603d-62213a446435@redhat.com> (raw)
In-Reply-To: <20190625152852.6xbswgit7f5gszq5@steredhat>
[-- Attachment #1.1: Type: text/plain, Size: 3088 bytes --]
On 25.06.19 17:28, Stefano Garzarella wrote:
> On Tue, Jun 25, 2019 at 04:57:53PM +0200, Max Reitz wrote:
>> On 25.06.19 16:47, Stefano Garzarella wrote:
>>> On Tue, Jun 25, 2019 at 04:02:04PM +0200, Max Reitz wrote:
>>>> On 09.05.19 16:59, Stefano Garzarella wrote:
>>>>> RBD APIs don't allow us to write more than the size set with
>>>>> rbd_create() or rbd_resize().
>>>>> In order to support growing images (eg. qcow2), we resize the
>>>>> image before write operations that exceed the current size.
>>>>>
>>>>> Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
>>>>> ---
>>>>> v3:
>>>>> - add 'image_size' field in the BDRVRBDState to keep track of the
>>>>> current size of the RBD image [Jason, Kevin]
>>>>> ---
>>>>> block/rbd.c | 42 +++++++++++++++++++++++++++++++++++++++---
>>>>> 1 file changed, 39 insertions(+), 3 deletions(-)
>>>>>
>>>>> diff --git a/block/rbd.c b/block/rbd.c
>>>>> index 0c549c9935..b0355a2ce0 100644
>>>>> --- a/block/rbd.c
>>>>> +++ b/block/rbd.c
>>>>
>>>> [...]
>>>>
>>>>> @@ -833,6 +842,22 @@ static void qemu_rbd_close(BlockDriverState *bs)
>>>>> rados_shutdown(s->cluster);
>>>>> }
>>>>>
>>>>> +/* Resize the RBD image and update the 'image_size' with the current size */
>>>>> +static int qemu_rbd_resize(BlockDriverState *bs, uint64_t size)
>>>>> +{
>>>>> + BDRVRBDState *s = bs->opaque;
>>>>> + int r;
>>>>> +
>>>>> + r = rbd_resize(s->image, size);
>>>>> + if (r < 0) {
>>>>> + return r;
>>>>> + }
>>>>> +
>>>>> + s->image_size = size;
>>>>
>>>> I think this should update bs->total_sectors, too. In fact, I’m
>>>> wondering why you don’t just use bs->total_sectors (or bdrv_getlength(),
>>>> which returns bs->total_sectors * 512) instead of adding this new field?
>>>>
>>>
>>> Hi Max,
>>> thanks for taking a look!
>>>
>>> I used bs->total_sectors in the v2, but Jason pointed out a possible
>>> issue with this, so I proposed to add a variable in the BDRVRBDState to
>>> track the latest resize and Kevin acked [1].
>>>
>>> IIUC what Kevin said on his comment, the 'bs->total_sectors' should be
>>> updated by bdrv_co_write_req_finish(), for this reason I didn't update
>>> it.
>>>
>>> [1] https://www.mail-archive.com/qemu-devel@nongnu.org/msg615195.html
>>
>> Ah, right! Yeah, sure, now that I think about it, the block layer must
>> have general code for successful writes beyond EOF... (Read: Now that
>> I’m pointed towards it...)
>
> Yeah, do you mean for example to call .bdrv_co_truncate() (or a new
> callback implemented only in the driver that need to be resized like
> rbd) in the bdrv_driver_pwritev() if we will write beyond EOF?
No, I just mean that in theory all drivers should support resizing by
writing beyond the EOF (in practice, it only matters for protocol
drivers). The general block layer code needs to recognize this and
handle it as if the BDS was explicitly resized with bdrv_co_truncate().
And it does do that, specifically in bdrv_co_write_req_finish(), as you
wrote.
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
prev parent reply other threads:[~2019-06-25 15:53 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-09 14:59 [Qemu-devel] [PATCH v3] block/rbd: increase dynamically the image size Stefano Garzarella
2019-05-21 8:56 ` [Qemu-devel] [Qemu-block] " Stefano Garzarella
2019-06-25 10:47 ` Stefano Garzarella
2019-06-25 14:02 ` [Qemu-devel] " Max Reitz
2019-06-25 14:47 ` Stefano Garzarella
2019-06-25 14:57 ` Max Reitz
2019-06-25 15:28 ` Stefano Garzarella
2019-06-25 15:48 ` Max Reitz [this message]
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=14d11ff9-b96b-47d0-603d-62213a446435@redhat.com \
--to=mreitz@redhat.com \
--cc=jdillama@redhat.com \
--cc=jdurgin@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=sgarzare@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).