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.5 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,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 4301FC433E1 for ; Mon, 17 Aug 2020 10:11:18 +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 F24C32067C for ; Mon, 17 Aug 2020 10:11:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="bpNp8c/U" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F24C32067C 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 ([::1]:44922 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1k7c6n-0003ZA-5Q for qemu-devel@archiver.kernel.org; Mon, 17 Aug 2020 06:11:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35726) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1k7c61-0002vg-Dq for qemu-devel@nongnu.org; Mon, 17 Aug 2020 06:10:29 -0400 Received: from us-smtp-delivery-1.mimecast.com ([207.211.31.120]:44483 helo=us-smtp-1.mimecast.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1k7c5y-0006Tq-JU for qemu-devel@nongnu.org; Mon, 17 Aug 2020 06:10:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1597659025; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=g0S9dELHctsr0xLhkBaCmqhqqVe7Wgm6WREL/3d+ksk=; b=bpNp8c/U2mSOj4uH8ZXIvkGRj7BLQ0dpsV2Mk5WrveApo8WKexfY/I/Cjx40g6N8uMgVXj Zaufh8af8wVwqxHrvtUpt6vyDjiV0nFhCzN+nWHxVd4nkEx8kKvvP8gkJ1IwEDpmc9QJxG T+5Fys7xkmnFlvliDf6WH30Uc9GfPXw= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-65-PPcGNad4PsCz7-zQMg00Zw-1; Mon, 17 Aug 2020 06:10:23 -0400 X-MC-Unique: PPcGNad4PsCz7-zQMg00Zw-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7B8C51006703; Mon, 17 Aug 2020 10:10:22 +0000 (UTC) Received: from linux.fritz.box (ovpn-112-160.ams2.redhat.com [10.36.112.160]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2A32821E82; Mon, 17 Aug 2020 10:10:20 +0000 (UTC) Date: Mon, 17 Aug 2020 12:10:19 +0200 From: Kevin Wolf To: Alberto Garcia Subject: Re: [PATCH 0/1] qcow2: Skip copy-on-write when allocating a zero cluster Message-ID: <20200817101019.GD11402@linux.fritz.box> References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=kwolf@redhat.com X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Received-SPF: pass client-ip=207.211.31.120; envelope-from=kwolf@redhat.com; helo=us-smtp-1.mimecast.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/17 00:24:04 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -30 X-Spam_score: -3.1 X-Spam_bar: --- X-Spam_report: (-3.1 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-1, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org, qemu-block@nongnu.org, Max Reitz Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Am 14.08.2020 um 16:57 hat Alberto Garcia geschrieben: > Hi, > > the patch is self-explanatory, but I'm using the cover letter to raise > a couple of related questions. > > Since commit c8bb23cbdbe / QEMU 4.1.0 (and if the storage backend > allows it) writing to an image created with preallocation=metadata can > be slower (20% in my tests) than writing to an image with no > preallocation at all. A while ago we had a case where commit c8bb23cbdbe was actually reported as a major performance regression, so it's a big "it depends". XFS people told me that they consider this code a bad idea. Just because it's a specialised "write zeroes" operation, it's not necessarily fast on filesystems. In particular, on XFS, ZERO_RANGE causes a queue drain with O_DIRECT (probably hurts cases with high queue depths) and additionally even a page cache flush without O_DIRECT. So in a way this whole thing is a two-edged sword. > So: > > a) shall we include a warning in the documentation ("note that this > preallocation mode can result in worse performance")? To be honest, I don't really understand this case yet. With metadata preallocation, the clusters are already marked as allocated, so why would handle_alloc_space() even be called? We're not allocating new clusters after all? Or are you saying that ZERO_RANGE + pwrite on a sparse file (= cluster allocation) is faster for you than just the pwrite alone (= writing to already allocated cluster)? > b) why don't we also initialize preallocated clusters with > QCOW_OFLAG_ZERO? (at least when there's no subclusters involved, > i.e. no backing file). This would make reading from them (and > writing to them, after this patch) faster. Because the idea with metadata preallocation is that you don't have to perform any COW and update any metdata because everything is already allocated. If you set the zero flag, you get cluster allocations with COW again, defeating the whole purpose of the preallocation. Kevin