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=-5.1 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 D2D93C433DB for ; Wed, 17 Mar 2021 08:10:52 +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 2D4D364F92 for ; Wed, 17 Mar 2021 08:10:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2D4D364F92 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]:55208 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lMRGV-0003sz-6s for qemu-devel@archiver.kernel.org; Wed, 17 Mar 2021 04:10:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52472) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lMRFg-0002zf-1E for qemu-devel@nongnu.org; Wed, 17 Mar 2021 04:10:00 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:47531) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.90_1) (envelope-from ) id 1lMRFc-0002Wv-Av for qemu-devel@nongnu.org; Wed, 17 Mar 2021 04:09:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1615968594; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KibSYtgw08q+WmXa+ECBzHD/TPmZg47jXMEEUJmnx8s=; b=hn8wvLAz1FhIU6SA1fr7TNXZ6ehm8JsOGMGYvaH1Ab+9Qz/fs8CeKqXs6Uqp9WBIdVg6V/ 8rglksvAahO9SLZ9XJ0M+a9re6J4A4jtFMC+y/6Kqlv3uIFDEG9BDEQeLfvwrt2aib05FI sFSuPbXREjJ1Y6Qmo1UmKIA+aB7vcfY= 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-484-Jf79oABvN6GWA-nLG3Vjow-1; Wed, 17 Mar 2021 04:09:52 -0400 X-MC-Unique: Jf79oABvN6GWA-nLG3Vjow-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 59573107ACCD; Wed, 17 Mar 2021 08:09:51 +0000 (UTC) Received: from dresden.str.redhat.com (ovpn-113-160.ams2.redhat.com [10.36.113.160]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B3A4B19704; Wed, 17 Mar 2021 08:09:49 +0000 (UTC) Subject: Re: [PATCH v3 6/6] block/qcow2: use seqcache for compressed writes To: Vladimir Sementsov-Ogievskiy , qemu-block@nongnu.org References: <20210305173507.393137-1-vsementsov@virtuozzo.com> <20210305173507.393137-7-vsementsov@virtuozzo.com> <6056196d-a0cc-7de2-5d6f-b223fdee98ff@redhat.com> <7fb10a80-8001-966d-533e-3f74c739571a@virtuozzo.com> From: Max Reitz Message-ID: <28f3c53f-fe0b-9a55-22b8-a6f016c5f52b@redhat.com> Date: Wed, 17 Mar 2021 09:09:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 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=mreitz@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=63.128.21.124; envelope-from=mreitz@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -29 X-Spam_score: -3.0 X-Spam_bar: --- X-Spam_report: (-3.0 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable 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: kwolf@redhat.com, jsnow@redhat.com, qemu-devel@nongnu.org, ehabkost@redhat.com, crosa@redhat.com Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On 16.03.21 18:48, Vladimir Sementsov-Ogievskiy wrote: > 16.03.2021 15:25, Max Reitz wrote: >> On 15.03.21 15:40, Vladimir Sementsov-Ogievskiy wrote: >>> 15.03.2021 12:58, Max Reitz wrote: >> >> [...] >> >>>> The question is whether it really makes sense to even have a >>>> seqcache_read() path when in reality it’s probably never accessed. >>>> I mean, besides the fact that it seems based purely on chance >>>> whether a read might fetch something from the cache even while we’re >>>> writing, in practice I don’t know any case where we’d write to and >>>> read from a compressed qcow2 image at the same time.  (I don’t know >>>> what you’re doing with the 'compress' filter, though.) >>>> >>> >>> Note, that for user that's not a parallel write and read to the same >>> cluster: >>> >>> 1. user writes cluster A, request succeeded, data is in the cache >>> >>> 2. user writes some other clusters, cache filled, flush started >>> >>> 3. in parallel to [2] user reads cluster A. From the POV of user, >>> cluster A is written already, and should be read successfully >> >> Yes, but when would that happen? >> >>> And seqcache_read() gives a simple non-blocking way to support read >>> operation. >> >> OK, that makes sense.  We’d need to flush the cache before we can read >> anything from the disk, so we should have a read-from-cache branch here. >> >>> But rewriting compressed clusters is sensible only when we run real >>> guest on compressed image.. Can it be helpful? Maybe for scenarios >>> with low disk usage ratio.. >> >> I’m not sure, but the point is that rewrites are currently not >> supported.  The whole compression implementation is mainly tailored >> towards just writing a complete image (e.g. by qemu-img convert or the >> backup job), so that’s where my question is coming from: It’s >> difficult for me to see a currently working use case where you’d read >> from and write to a compressed image at the same time. >> > > External backup works like the following: > >  - start backup sync=none from active disk to temporary disk >  - export temporary disk through nbd >  - external tool reads from nbd export > > For this scheme it may make sense to use compression, Not sure whether it really does, because it’s my impression the temporary disk is deleted after the backup, but no matter: You’re right, that’s indeed a valid case. Max