From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxD0r-0005Sw-Po for qemu-devel@nongnu.org; Sat, 06 Dec 2014 05:55:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XxD0i-0005AJ-Ng for qemu-devel@nongnu.org; Sat, 06 Dec 2014 05:54:57 -0500 Received: from mail-pa0-x229.google.com ([2607:f8b0:400e:c03::229]:52423) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XxD0i-0005AF-FZ for qemu-devel@nongnu.org; Sat, 06 Dec 2014 05:54:48 -0500 Received: by mail-pa0-f41.google.com with SMTP id rd3so2279694pab.28 for ; Sat, 06 Dec 2014 02:54:47 -0800 (PST) Date: Sat, 6 Dec 2014 18:54:41 +0800 From: Jun Li Message-ID: <20141206105440.GA5805@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [Qemu-devel] (no subject) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: josh.durgin@inktank.com, juli@redhat.com, qemu-devel@nongnu.org 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 >