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=-3.8 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 2BD38C433ED for ; Thu, 22 Apr 2021 05:16:39 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B24236144A for ; Thu, 22 Apr 2021 05:16:38 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B24236144A Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=bugs.launchpad.net Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:37758 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lZRhd-0000Yx-J3 for qemu-devel@archiver.kernel.org; Thu, 22 Apr 2021 01:16:37 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55334) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lZRg9-0007kG-W0 for qemu-devel@nongnu.org; Thu, 22 Apr 2021 01:15:06 -0400 Received: from indium.canonical.com ([91.189.90.7]:48738) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lZRg3-0006ys-Ab for qemu-devel@nongnu.org; Thu, 22 Apr 2021 01:15:02 -0400 Received: from loganberry.canonical.com ([91.189.90.37]) by indium.canonical.com with esmtp (Exim 4.86_2 #2 (Debian)) id 1lZRg0-0001st-4G for ; Thu, 22 Apr 2021 05:14:56 +0000 Received: from loganberry.canonical.com (localhost [127.0.0.1]) by loganberry.canonical.com (Postfix) with ESMTP id 1F7042E8157 for ; Thu, 22 Apr 2021 05:14:56 +0000 (UTC) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Thu, 22 Apr 2021 05:03:17 -0000 From: Thomas Huth <1538541@bugs.launchpad.net> To: qemu-devel@nongnu.org X-Launchpad-Notification-Type: bug X-Launchpad-Bug: product=qemu; status=Incomplete; importance=Undecided; assignee=None; X-Launchpad-Bug-Information-Type: Public X-Launchpad-Bug-Private: no X-Launchpad-Bug-Security-Vulnerability: no X-Launchpad-Bug-Commenters: berrange kwolf-redhat th-huth xanclic X-Launchpad-Bug-Reporter: Daniel Berrange (berrange) X-Launchpad-Bug-Modifier: Thomas Huth (th-huth) References: <20160127125558.31349.12989.malonedeb@gac.canonical.com> Message-Id: <161906779753.6578.7832520806445199721.malone@chaenomeles.canonical.com> Subject: [Bug 1538541] Re: qcow2 rejects request to use preallocation with backing file X-Launchpad-Message-Rationale: Subscriber (QEMU) @qemu-devel-ml X-Launchpad-Message-For: qemu-devel-ml Precedence: bulk X-Generated-By: Launchpad (canonical.com); Revision="1552fceb1603b3da6cfa437575d9c9fc4b2e683a"; Instance="production" X-Launchpad-Hash: a1c7862c4590e7b240686fc1c3555ea45f66d9ea Received-SPF: none client-ip=91.189.90.7; envelope-from=bounces@canonical.com; helo=indium.canonical.com X-Spam_score_int: -65 X-Spam_score: -6.6 X-Spam_bar: ------ X-Spam_report: (-6.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Bug 1538541 <1538541@bugs.launchpad.net> Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now. If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or please mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience. ** Changed in: qemu Status: New =3D> Incomplete -- = You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1538541 Title: qcow2 rejects request to use preallocation with backing file Status in QEMU: Incomplete Bug description: The 'preallocation=3Dfull' option to qemu-img / qcow2 block driver instructs QEMU to fully allocate the host file to the maximum size needed by the logical disk size. $ qemu-img create -f qcow2 -o preallocation=3Dfull base.qcow2 200M Formatting 'base.qcow2', fmt=3Dqcow2 size=3D209715200 encryption=3Doff cl= uster_size=3D65536 preallocation=3D'full' lazy_refcounts=3Doff refcount_bit= s=3D16 $ ls -alhs base.qcow2 = 201M -rw-r--r--. 1 berrange berrange 201M Jan 27 12:49 base.qcow2 = When specifying a backing file for the qcow2 file, however, it rejects th= e preallocation request $ qemu-img create -f qcow2 -o preallocation=3Dfull,backing_file=3Dbase.qc= ow2 front.qcow2 200M Formatting 'front.qcow2', fmt=3Dqcow2 size=3D209715200 backing_file=3D'ba= se.qcow2' encryption=3Doff cluster_size=3D65536 preallocation=3D'full' lazy= _refcounts=3Doff refcount_bits=3D16 qemu-img: front.qcow2: Backing file and preallocation cannot be used at t= he same time = It might seem like requesting full preallocation is redundant because mos= t data associated with the image will be present in the backing file, as so= the top layer is unlikely to ever need the full preallocation. Rejecting = this, however, means it is not (officially) possible to reserve disk space = for the top layer to guarantee that future copy-on-writes will never get EN= OSPC. OpenStack in particular uses backing files with all images, in order to avoid the I/O overhead of copying the backing file contents into the per-VM disk image. It, however, still wants to have a guarantee that the per-VM image will never hit an ENOSPC scenario. Currently it has to hack around QEMU's refusal to allow backing_file + preallocation, by calling 'fallocate' on the qcow2 file after it has been created. This is an inexact fix though, because it doesn't take account of fact that qcow2 metadata can takes some MBs of space. Thus, it would like to see preallocation=3Dfull supported in combination with backing files. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1538541/+subscriptions