All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jun Li <junmuzi@gmail.com>
To: Max Reitz <mreitz@redhat.com>
Cc: josh.durgin@inktank.com, juli@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] your mail
Date: Sat, 6 Dec 2014 19:17:04 +0800	[thread overview]
Message-ID: <20141206111704.GA11311@localhost.localdomain> (raw)
In-Reply-To: <20141206105440.GA5805@localhost.localdomain>

Please ignore it. Sorry...

On Sat, 12/06 18:54, Jun Li wrote:
> stefanha@redhat.com
> Bcc: 
> Subject: Re: [Qemu-devel] qcow2: Can create qcow2 image format on rbd server
> Reply-To: 
> In-Reply-To: <5481E4E7.9010402@redhat.com>
> 
> On Fri, 12/05 18:01, Max Reitz wrote:
> > On 2014-12-05 at 16:32, Jun Li wrote:
> > >Currently, qemu-img can not create qcow2 image format on rbd server. Analysis
> > >the code as followings:
> > >when create qcow2 format image:
> > >qcow2_create2
> > >   bdrv_create_file(filename, opts, &local_err);  --> Here will create a 0 size
> > >   file(e.g: file1) on rbd server.
> > >   ...
> > >   ret = bdrv_pwrite(bs, 0, header, cluster_size); --> So here can not write
> > >   qcow2 header into file1 due to the file1's length is 0. Seems
> > >   qemu_rbd_aio_writev can not write beyond EOF.
> > >   ...
> > >
> > >As above analysis, there are two methods to solve the above bz as followings:
> > >1, When create file1, just create a fixed-size file1 on rbd server(not 0 size).
> > 
> > Should be possible by using -o preallocation=falloc or -o
> > preallocation=full.
> 
> Sure. If bdrv_create_file(filename, opts, &local_err) create a fixed-size(not
> 0 size) just as using "preallocation=falloc or preallocation=full", it will
> create a fixed-size file on rbd server. So it won't exist above issue.
> 
> > 
> > I can't say a lot about making rbd growable because I know near to nothing
> > about rbd; but there are protocols which really simply don't support writes
> > beyond the end of file, and where that's intended (for instance, while nbd
> > somehow does support it when using the qemu nbd server, normally (strictly
> > according to the protocol) it does not); so for these protocols, you have to
> > use a preallocated image file or an image format which does not grow on
> > writes (such as raw).
> > 
> 
> Here just want to use rbd_resize to realize rbd growable.
> 
> > Of course, while that may be a solution for nbd, it doesn't sound like a
> > good solution for rbd, so writes beyond the EOF should probably be supported
> > there (although once again, I don't know rbd well enough to judge that).
> > 
> 
> Yes, you are right. Also talked with stefan. Here just want to ask Josh Durgin
> whether it has other solutions or rbd can support asynchronous rbd_resize.
> 
> Regards,
> Jun Li
> 
> > 
> > >2, When write the qcow2 header into file1, just let qemu_rbd_aio_writev can
> > >enlarge the file1. So should add qemu_rbd_truncate inside qemu_rbd_aio_writev.
> > >qemu_rbd_truncate will call rbd_resize, but seems rbd_resize is
> > >synchronous function. If so, when do bdrv_pwrite, guest will hang.This is not
> > >our expected.
> > >
> > >For method 1, maybe it's not corresponding to the original principle of qcow2.
> > >Yes, it's very easy to solve the above bz. Nevertheless, I just want to use
> > >method 2 to solve above issue.
> > >
> > >For method 2, could anyone give some suggestions on howto realize a
> > >asynchronous rbd_resize. Thanks.
> > >
> > >Above analysis also based on stefan's hints. Thanks.
> > >
> > >Best Regards,
> > >Jun Li
> > 

  reply	other threads:[~2014-12-06 11:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-06 10:54 [Qemu-devel] (no subject) Jun Li
2014-12-06 11:17 ` Jun Li [this message]
  -- strict thread matches above, loose matches on Subject: below --
2016-11-16 19:41 Christopher Oliver
2016-11-17 10:35 ` [Qemu-devel] your mail Kevin Wolf
2018-06-20  7:32 [Qemu-devel] [PATCH v5 0/7] monitor: enable OOB by default Peter Xu
2018-06-26 17:21 ` [Qemu-devel] (no subject) Markus Armbruster
2018-06-27 11:59   ` [Qemu-devel] your mail Peter Xu
2018-06-28  8:31     ` Markus Armbruster
2018-06-28 11:51       ` Eric Blake
2018-06-28 12:00       ` Daniel P. Berrangé
2018-06-29  9:57         ` Peter Xu
2018-06-29 15:40           ` Eric Blake

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=20141206111704.GA11311@localhost.localdomain \
    --to=junmuzi@gmail.com \
    --cc=josh.durgin@inktank.com \
    --cc=juli@redhat.com \
    --cc=mreitz@redhat.com \
    --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 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.