From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:47864) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyBqv-0007bK-TJ for qemu-devel@nongnu.org; Mon, 08 Dec 2014 22:52:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XyBqn-0005Iu-S4 for qemu-devel@nongnu.org; Mon, 08 Dec 2014 22:52:45 -0500 Received: from mail-pd0-f176.google.com ([209.85.192.176]:49337) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XyBqn-0005IR-Ma for qemu-devel@nongnu.org; Mon, 08 Dec 2014 22:52:37 -0500 Received: by mail-pd0-f176.google.com with SMTP id y10so6432624pdj.35 for ; Mon, 08 Dec 2014 19:52:36 -0800 (PST) Message-ID: <54867206.6090009@inktank.com> Date: Mon, 08 Dec 2014 19:52:38 -0800 From: Josh Durgin MIME-Version: 1.0 References: <20141205153210.GA4573@localhost.localdomain> <5481E4E7.9010402@redhat.com> <20141208135827.GB2836@localhost.localdomain> In-Reply-To: <20141208135827.GB2836@localhost.localdomain> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qcow2: Can create qcow2 image format on rbd server List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jun Li , Max Reitz Cc: juli@redhat.com, qemu-devel@nongnu.org On 12/08/2014 05:58 AM, Jun Li wrote: > 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. > > Although "-o preallocation=falloc or -o preallocation=full" can create a qcow2 > format image successfully, but when perform "qemu-img resize file.qcow2 > +500M", then use the extend 500M disk image still hit the same issue(as rbd > block driver does not support growable file). Why not use 'rbd resize' and raw images instead? rbd already supports snapshots, cloning, thin provisioning, and differential backup natively, so putting qcow2 on top tends to just add overhead. Josh > So use "-o preallocation=falloc or -o preallocation=full", it not a good > solution. > > Regards, > Jun Li > >> >> 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). >> >> 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). >> >> Max >> >>> 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 >> >