qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefano Garzarella <sgarzare@redhat.com>
To: qemu-devel@nongnu.org
Cc: qemu-block@nongnu.org, Max Reitz <mreitz@redhat.com>,
	Josh Durgin <jdurgin@redhat.com>, Kevin Wolf <kwolf@redhat.com>
Subject: [Qemu-devel] [PATCH RFC 0/1] block/rbd: increase dynamically the image size
Date: Thu, 11 Apr 2019 12:50:24 +0200	[thread overview]
Message-ID: <20190411105025.97397-1-sgarzare@redhat.com> (raw)

RBD APIs don't allow us to write more than the maximum size of the file set
with rbd_create() or rbd_resize(), so we are not able to create/use a qcow2
image with the rbd driver.

What I found is the following:
- when qcow2 uses the rbd driver, the new file is created (rbd_create)
  with the size equals to 0. (qemu_opt_get_size_del(opts,
  BLOCK_OPT_SIZE, 0) returns 0 in qemu_rbd_co_create_opts())
- the file is truncated (implemented with rbd_resize) to 0 before to
  write the qcow2 header.
- the "size" parameter passed to rbd_create() or rbd_resize() is
  interpreted as the maximum size of the file, this means that all
  writes that exceed that size, fails and returns -22.

As a workaround, I'm checking if the RW operations exceed the maximum
size and then I'll resize the file. It works, but I'm not sure it is the
right way.

Any suggestions?

Thanks,
Stefano

Stefano Garzarella (1):
  block/rbd: increase dynamically the image size

 block/rbd.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

-- 
2.20.1

WARNING: multiple messages have this Message-ID (diff)
From: Stefano Garzarella <sgarzare@redhat.com>
To: qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Josh Durgin <jdurgin@redhat.com>,
	qemu-block@nongnu.org, Max Reitz <mreitz@redhat.com>
Subject: [Qemu-devel] [PATCH RFC 0/1] block/rbd: increase dynamically the image size
Date: Thu, 11 Apr 2019 12:50:24 +0200	[thread overview]
Message-ID: <20190411105025.97397-1-sgarzare@redhat.com> (raw)
Message-ID: <20190411105024.zrDG1Qgn67bhV4zlRRRI703D0Ih-jsFP_IpueYmd9L4@z> (raw)

RBD APIs don't allow us to write more than the maximum size of the file set
with rbd_create() or rbd_resize(), so we are not able to create/use a qcow2
image with the rbd driver.

What I found is the following:
- when qcow2 uses the rbd driver, the new file is created (rbd_create)
  with the size equals to 0. (qemu_opt_get_size_del(opts,
  BLOCK_OPT_SIZE, 0) returns 0 in qemu_rbd_co_create_opts())
- the file is truncated (implemented with rbd_resize) to 0 before to
  write the qcow2 header.
- the "size" parameter passed to rbd_create() or rbd_resize() is
  interpreted as the maximum size of the file, this means that all
  writes that exceed that size, fails and returns -22.

As a workaround, I'm checking if the RW operations exceed the maximum
size and then I'll resize the file. It works, but I'm not sure it is the
right way.

Any suggestions?

Thanks,
Stefano

Stefano Garzarella (1):
  block/rbd: increase dynamically the image size

 block/rbd.c | 25 +++++++++++++++++++++++++
 1 file changed, 25 insertions(+)

-- 
2.20.1



             reply	other threads:[~2019-04-11 10:50 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 10:50 Stefano Garzarella [this message]
2019-04-11 10:50 ` [Qemu-devel] [PATCH RFC 0/1] block/rbd: increase dynamically the image size Stefano Garzarella
2019-04-11 10:50 ` [Qemu-devel] [PATCH RFC 1/1] " Stefano Garzarella
2019-04-11 10:50   ` Stefano Garzarella
2019-04-11 12:35   ` Jason Dillaman
2019-04-11 12:35     ` Jason Dillaman
2019-04-11 13:02     ` Stefano Garzarella
2019-04-11 13:02       ` Stefano Garzarella
2019-04-11 17:06       ` Jason Dillaman
2019-04-11 17:06         ` Jason Dillaman
2019-04-14 13:20         ` Stefano Garzarella
2019-04-14 13:20           ` Stefano Garzarella
2019-04-14 15:14           ` Jason Dillaman
2019-04-14 15:14             ` Jason Dillaman
2019-04-15  8:04             ` Kevin Wolf
2019-04-15  8:04               ` Kevin Wolf
2019-04-17  7:34               ` Stefano Garzarella
2019-04-17  7:34                 ` Stefano Garzarella
2019-04-17  8:04                 ` Kevin Wolf
2019-04-17  8:04                   ` Kevin Wolf
2019-04-19 12:23                   ` Stefano Garzarella
2019-04-19 12:23                     ` Stefano Garzarella
2019-04-23  7:56                     ` Kevin Wolf
2019-04-23  7:56                       ` Kevin Wolf
2019-04-23  8:26                       ` Stefano Garzarella
2019-04-23  8:26                         ` Stefano Garzarella
2019-04-23  8:38                         ` Kevin Wolf
2019-04-23  8:38                           ` Kevin Wolf
2019-04-29  9:58                           ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2019-04-29  9:58                             ` Kevin Wolf
2019-04-29 10:11                             ` Stefano Garzarella
2019-04-29 10:11                               ` Stefano Garzarella
2019-04-29 10:25   ` [Qemu-devel] " Kevin Wolf
2019-04-29 10:25     ` Kevin Wolf
2019-04-29 14:04     ` Stefano Garzarella
2019-04-29 14:04       ` Stefano Garzarella
2019-04-29 14:30       ` Kevin Wolf
2019-04-29 14:30         ` Kevin Wolf
2019-04-29 15:55         ` Stefano Garzarella
2019-04-29 15:55           ` Stefano Garzarella

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=20190411105025.97397-1-sgarzare@redhat.com \
    --to=sgarzare@redhat.com \
    --cc=jdurgin@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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).