From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([209.51.188.92]:45736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEdAF-00074Y-1B for qemu-devel@nongnu.org; Thu, 11 Apr 2019 13:07:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEdAD-0001z4-Ui for qemu-devel@nongnu.org; Thu, 11 Apr 2019 13:07:03 -0400 Received: from mail-ed1-f46.google.com ([209.85.208.46]:38192) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hEdAD-0001xY-J7 for qemu-devel@nongnu.org; Thu, 11 Apr 2019 13:07:01 -0400 Received: by mail-ed1-f46.google.com with SMTP id d13so5877522edr.5 for ; Thu, 11 Apr 2019 10:07:01 -0700 (PDT) MIME-Version: 1.0 References: <20190411105025.97397-1-sgarzare@redhat.com> <20190411105025.97397-2-sgarzare@redhat.com> <20190411130245.ltfyp7d2dfe2cr3h@steredhat> In-Reply-To: <20190411130245.ltfyp7d2dfe2cr3h@steredhat> Reply-To: dillaman@redhat.com From: Jason Dillaman Date: Thu, 11 Apr 2019 13:06:49 -0400 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] [PATCH RFC 1/1] block/rbd: increase dynamically the image size List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefano Garzarella Cc: dillaman , qemu-devel , Kevin Wolf , Josh Durgin , qemu-block , Max Reitz On Thu, Apr 11, 2019 at 9:02 AM Stefano Garzarella wrote: > > On Thu, Apr 11, 2019 at 08:35:44AM -0400, Jason Dillaman wrote: > > On Thu, Apr 11, 2019 at 7:00 AM 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 RW operations that exceed the current size. > > > > What's the use-case for storing qcow2 images within a RBD image? RBD > > images are already thinly provisioned, they support snapshots, they > > can form a parent/child linked image hierarchy. > > > > Hi Jason, > I understand your point of view, maybe one use case could be if you have > a qcow2 image and you want to put it in the rdb pool without convert it. > > I'm going through this BZ [1] and I'll ask if they have other > use cases in mind. Assuming no good use-cases, perhaps it would just be better to make the qemu-img error messages more clear. > Anyway, if we want to support only raw format on RBD driver, maybe we > should return something different from current behaviour, also avoiding > to create the image: > > $ qemu-img create -f qcow2 rbd:test/qcow.img 1G > qemu-img: rbd:test/qcow.img: Could not write qcow2 header: Invalid argument > > What do you think? > > Thanks, > Stefano > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1171007 -- Jason From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 881A1C10F13 for ; Thu, 11 Apr 2019 17:07:57 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 0C16620818 for ; Thu, 11 Apr 2019 17:07:56 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0C16620818 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([127.0.0.1]:52325 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEdB5-0007QF-56 for qemu-devel@archiver.kernel.org; Thu, 11 Apr 2019 13:07:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45736) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hEdAF-00074Y-1B for qemu-devel@nongnu.org; Thu, 11 Apr 2019 13:07:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hEdAD-0001z4-Ui for qemu-devel@nongnu.org; Thu, 11 Apr 2019 13:07:03 -0400 Received: from mail-ed1-f46.google.com ([209.85.208.46]:38192) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hEdAD-0001xY-J7 for qemu-devel@nongnu.org; Thu, 11 Apr 2019 13:07:01 -0400 Received: by mail-ed1-f46.google.com with SMTP id d13so5877522edr.5 for ; Thu, 11 Apr 2019 10:07:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=1OpuT5+EyVVVDbsIOdaFbG+ZYNhAy0foMVhSSX5IlnY=; b=VXFVLaHCZo+SExMPcpi1qoiWn8Mpe9lVLaNYn6HR0WHc1edNy7WIqRZA0PoMxV3LQI KutnkhdN3fW1+VzuY1xg7ebYRiXrtonqu7jOPSY7cLHbDpr7QVsHZ5iqXQCIq4F8UFoG PFJO8HlhE5FT2IhfejWUcxpboYdJ6rE170PQ/mhcOYwayMV0BsZT0djsLuUkcTiqE0vN EDNBdyoRG9vPisFI6zvlbVFBye81eSDbnC7ZOYfuXikCEsYeur2R2u6mmtOiivUjaEUm HuCMuW/IsdR/fu4oLqjSAyQZbwKTir1WI/DQeo3YkUqCCRPGWFK9zVdEfvx0Yi0uUMda ptGg== X-Gm-Message-State: APjAAAUA9zO+LD4wzvPDY32Q55ZbHxPlJCWkAgU6Mn/FXFI9Gx7enweL H/b9MNZkxSy8tXY5RJ9kuHvZP9b6kMkYTGcK3znvSA== X-Google-Smtp-Source: APXvYqx9gd8tDNCPFY7FJlP9PG+DeNlvhINXfveay0tIdE2IkM85k710xfgfSQQ/ieDVV6sDrafWreJP1G/CvCCU94E= X-Received: by 2002:a50:8985:: with SMTP id g5mr11282600edg.65.1555002420424; Thu, 11 Apr 2019 10:07:00 -0700 (PDT) MIME-Version: 1.0 References: <20190411105025.97397-1-sgarzare@redhat.com> <20190411105025.97397-2-sgarzare@redhat.com> <20190411130245.ltfyp7d2dfe2cr3h@steredhat> In-Reply-To: <20190411130245.ltfyp7d2dfe2cr3h@steredhat> From: Jason Dillaman Date: Thu, 11 Apr 2019 13:06:49 -0400 Message-ID: To: Stefano Garzarella Content-Type: text/plain; charset="UTF-8" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.208.46 Subject: Re: [Qemu-devel] [PATCH RFC 1/1] block/rbd: increase dynamically the image size X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: dillaman@redhat.com Cc: Kevin Wolf , Josh Durgin , qemu-block , qemu-devel , Max Reitz , dillaman Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Message-ID: <20190411170649._qh1KOpBvcSQyETe_jjwnJpyMdRi_r7pdnPCpqCwZkk@z> On Thu, Apr 11, 2019 at 9:02 AM Stefano Garzarella wrote: > > On Thu, Apr 11, 2019 at 08:35:44AM -0400, Jason Dillaman wrote: > > On Thu, Apr 11, 2019 at 7:00 AM 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 RW operations that exceed the current size. > > > > What's the use-case for storing qcow2 images within a RBD image? RBD > > images are already thinly provisioned, they support snapshots, they > > can form a parent/child linked image hierarchy. > > > > Hi Jason, > I understand your point of view, maybe one use case could be if you have > a qcow2 image and you want to put it in the rdb pool without convert it. > > I'm going through this BZ [1] and I'll ask if they have other > use cases in mind. Assuming no good use-cases, perhaps it would just be better to make the qemu-img error messages more clear. > Anyway, if we want to support only raw format on RBD driver, maybe we > should return something different from current behaviour, also avoiding > to create the image: > > $ qemu-img create -f qcow2 rbd:test/qcow.img 1G > qemu-img: rbd:test/qcow.img: Could not write qcow2 header: Invalid argument > > What do you think? > > Thanks, > Stefano > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1171007 -- Jason