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 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 022FCC7EE2C for ; Fri, 2 Jun 2023 21:51:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1685742661; h=from:from:sender:sender: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:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=JwexpzA+Z03moQnqu2Mn4d8R+iHUo0nJKJnUCa9mbss=; b=J/A1EFwCLPW8wl9LevIfEE/L13fiJs3H/lZrfGDo3SyB3EiCI9JIMEeeUj6IgXsdz4iPTY C04J6s298M5HDv7GPmbZvT+cAOGh52Ldm0Ef5M/gwCfGYFk7GafaU1mK/pDz3aaTwHQuip VIHbazY9xmDP4DYpkaOtGuPVRH0UdlY= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-96-2VVvin7DMdaaAP5PpNg_CQ-1; Fri, 02 Jun 2023 17:50:58 -0400 X-MC-Unique: 2VVvin7DMdaaAP5PpNg_CQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 48D493C02B74; Fri, 2 Jun 2023 21:50:56 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (unknown [10.30.29.100]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5BC099E63; Fri, 2 Jun 2023 21:50:55 +0000 (UTC) Received: from mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (localhost [IPv6:::1]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 2A8771946595; Fri, 2 Jun 2023 21:50:55 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 0B26F194658C for ; Fri, 2 Jun 2023 21:50:53 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id CBA3DC154D9; Fri, 2 Jun 2023 21:50:53 +0000 (UTC) Received: from mimecast-mx02.redhat.com (mimecast07.extmail.prod.ext.rdu2.redhat.com [10.11.55.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C342AC154D7 for ; Fri, 2 Jun 2023 21:50:53 +0000 (UTC) Received: from us-smtp-inbound-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A73F43C025BA for ; Fri, 2 Jun 2023 21:50:53 +0000 (UTC) Received: from mail-qt1-f175.google.com (mail-qt1-f175.google.com [209.85.160.175]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-15-VnGPXxc7O6ut5rH_ZtBXVQ-1; Fri, 02 Jun 2023 17:50:52 -0400 X-MC-Unique: VnGPXxc7O6ut5rH_ZtBXVQ-1 Received: by mail-qt1-f175.google.com with SMTP id d75a77b69052e-3f8177f9a7bso23818821cf.2 for ; Fri, 02 Jun 2023 14:50:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685742652; x=1688334652; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UTRky113EniM0nT/xznU7UrijnGVH8CEk6F86K/tnEo=; b=Z5zBevlBvIVCwUqg7texHmPYRkUg4DIXHJnHK8YFEdur3SjsqSiTZxYwoKOWGfjDnP s3mLpMTih8Lve/iL8/8ZGhGsRy2OkodCmiwLS93a0Y+OFEoTbZ20ZJs67Ni1fBB8CYXQ 7egzhCq9N/xWMVl87q1oSLLPO0YLgcDvOzplVlNumV2kMsxTMSDCKMjq2KCvJAw5RetZ d5zOxVuZXu/drU5ls46dyesgmUXmhZnNDclhkjLKJvVvu9gHXlO5IWnCKfvTMkL/emmH CguTCSNl5ghryQb9/k2rDTVzejGc9QZWNkYa4MvCzr2xbeyMblUIQIchSseekpU0l9YE iswQ== X-Gm-Message-State: AC+VfDzGYzT7DZ/nvmq2WWOiJXtZRJLtMyuE7ipCa7vzrO+0V+4U9l2Z v1UdnM0zEEr2Z3M09OiaP4Han7M= X-Google-Smtp-Source: ACHHUZ7EYtrupkurG9n+8SFwQbMMRsCnns2grd76F2kWxvjetuxx5d1DqIPs4GPppwGqt5TFKDjmsg== X-Received: by 2002:ac8:5e11:0:b0:3f6:b017:6289 with SMTP id h17-20020ac85e11000000b003f6b0176289mr16977166qtx.10.1685742651495; Fri, 02 Jun 2023 14:50:51 -0700 (PDT) Received: from localhost (pool-68-160-166-30.bstnma.fios.verizon.net. [68.160.166.30]) by smtp.gmail.com with ESMTPSA id i2-20020ac813c2000000b003f6f83de87esm1236527qtj.92.2023.06.02.14.50.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Jun 2023 14:50:50 -0700 (PDT) Date: Fri, 2 Jun 2023 17:50:49 -0400 From: Mike Snitzer To: Sarthak Kukreti Message-ID: References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 Subject: Re: [dm-devel] [PATCH v7 0/5] Introduce provisioning primitives X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Jens Axboe , Christoph Hellwig , Joe Thornber , "Michael S. Tsirkin" , "Darrick J. Wong" , Jason Wang , Bart Van Assche , Dave Chinner , linux-kernel@vger.kernel.org, Joe Thornber , linux-block@vger.kernel.org, dm-devel@redhat.com, Andreas Dilger , Stefan Hajnoczi , linux-fsdevel@vger.kernel.org, Theodore Ts'o , linux-ext4@vger.kernel.org, Brian Foster , Alasdair Kergon Errors-To: dm-devel-bounces@redhat.com Sender: "dm-devel" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.5 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: kernel.org Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gRnJpLCBKdW4gMDIgMjAyMyBhdCAgMjo0NFAgLTA0MDAsClNhcnRoYWsgS3VrcmV0aSA8c2Fy dGhha2t1a3JldGlAY2hyb21pdW0ub3JnPiB3cm90ZToKCj4gT24gVHVlLCBNYXkgMzAsIDIwMjMg YXQgODoyOOKAr0FNIE1pa2UgU25pdHplciA8c25pdHplckBrZXJuZWwub3JnPiB3cm90ZToKPiA+ Cj4gPiBPbiBUdWUsIE1heSAzMCAyMDIzIGF0IDEwOjU1UCAtMDQwMCwKPiA+IEpvZSBUaG9ybmJl ciA8dGhvcm5iZXJAcmVkaGF0LmNvbT4gd3JvdGU6Cj4gPgo+ID4gPiBPbiBUdWUsIE1heSAzMCwg MjAyMyBhdCAzOjAy4oCvUE0gTWlrZSBTbml0emVyIDxzbml0emVyQGtlcm5lbC5vcmc+IHdyb3Rl Ogo+ID4gPgo+ID4gPiA+Cj4gPiA+ID4gQWxzbyBKb2UsIGZvciB5b3UgcHJvcG9zZWQgZG0tdGhp bnAgZGVzaWduIHdoZXJlIHlvdSBkaXN0aW5xdWlzaAo+ID4gPiA+IGJldHdlZW4gInByb3Zpc2lv biIgYW5kICJyZXNlcnZlIjogV291bGQgaXQgbWFrZSBzZW5zZSBmb3IgUkVRX01FVEEKPiA+ID4g PiAoZS5nLiBhbGwgWEZTIG1ldGFkYXRhKSB3aXRoIFJFUV9QUk9WSVNJT04gdG8gYmUgdHJlYXRl ZCBhcyBhbgo+ID4gPiA+IExCQS1zcGVjaWZpYyBoYXJkIHJlcXVlc3Q/ICBXaGVyZWFzIFJFUV9Q Uk9WSVNJT04gb24gaXRzIG93biBwcm92aWRlcwo+ID4gPiA+IG1vcmUgZnJlZWRvbSB0byBqdXN0 IHJlc2VydmUgdGhlIGxlbmd0aCBvZiBibG9ja3M/IChlLmcuIGZvciBYRlMKPiA+ID4gPiBkZWxh bGxvYyB3aGVyZSBMQkEgcmFuZ2UgaXMgdW5rbm93biwgYnV0IGRtLXRoaW5wIGNhbiBiZSBhc2tl ZCB0bwo+ID4gPiA+IHJlc2VydmUgc3BhY2UgdG8gYWNjb21vZGF0ZSBpdCkuCj4gPiA+ID4KPiA+ ID4KPiA+ID4gTXkgcHJvcG9zYWwgb25seSBpbnZvbHZlcyAncmVzZXJ2ZScuICBQcm92aXNpb25p bmcgd2lsbCBiZSBkb25lIGFzIHBhcnQgb2YKPiA+ID4gdGhlIHVzdWFsIGlvIHBhdGguCj4gPgo+ ID4gT0ssIEkgdGhpbmsgd2UnZCBkbyB3ZWxsIHRvIHBpbiBkb3duIHRoZSB0b3AtbGV2ZWwgYmxv Y2sgaW50ZXJmYWNlcyBpbgo+ID4gcXVlc3Rpb24uIEJlY2F1c2UgdGhpcyBwYXRjaHNldCdzIGJs b2NrIGludGVyZmFjZSBwYXRjaCAoMi81KSBoZWFkZXIKPiA+IHNheXM6Cj4gPgo+ID4gIlRoaXMg cGF0Y2ggYWxzbyBhZGRzIHRoZSBjYXBhYmlsaXR5IHRvIGNhbGwgZmFsbG9jYXRlKCkgaW4gbW9k ZSAwCj4gPiBvbiBibG9jayBkZXZpY2VzLCB3aGljaCB3aWxsIHNlbmQgUkVRX09QX1BST1ZJU0lP TiB0byB0aGUgYmxvY2sKPiA+IGRldmljZSBmb3IgdGhlIHNwZWNpZmllZCByYW5nZSwiCj4gPgo+ ID4gU28gaXQgd2lyZXMgdXAgYmxrZGV2X2ZhbGxvY2F0ZSgpIHRvIGNhbGwgYmxrZGV2X2lzc3Vl X3Byb3Zpc2lvbigpLiBBCj4gPiB1c2VyIG9mIFhGUyBjb3VsZCB0aGVuIHVzZSBmYWxsb2NhdGUo KSBmb3IgdXNlciBkYXRhIC0tIHdoaWNoIHdvdWxkCj4gPiBjYXVzZSB0aGlucCdzIHJlc2VydmUg dG8gX25vdF8gYmUgdXNlZCBmb3IgY3JpdGljYWwgbWV0YWRhdGEuCj4gPgo+ID4gVGhlIG9ubHkg d2F5IHRvIGRpc3RpbnF1aXNoIHRoZSBjYWxsZXIgKGJldHdlZW4gb24tYmVoYWxmIG9mIHVzZXIg ZGF0YQo+ID4gdnMgWEZTIG1ldGFkYXRhKSB3b3VsZCBiZSBSRVFfTUVUQT8KPiA+Cj4gPiBTbyBz aG91bGQgZG0tdGhpbnAgaGF2ZSBhIFJFUV9NRVRBLWJhc2VkIGRpc3RpbmN0aW9uPyBPciBqdXN0 IHRyZWF0Cj4gPiBhbGwgUkVRX09QX1BST1ZJU0lPTiB0aGUgc2FtZT8KPiA+Cj4gSSdtIGluIGZh dm9yIG9mIGEgUkVRX01FVEEtYmFzZWQgZGlzdGluY3Rpb24uIERvZXMgdGhhdCBpbXBseSB0aGF0 Cj4gUkVRX01FVEEgYWxzbyBuZWVkcyB0byBiZSBwYXNzZWQgdGhyb3VnaCB0aGUgYmxvY2svZmls ZXN5c3RlbSBzdGFjawo+IChlZy4gUkVRX09QX1BST1ZJT04gKyBSRVFfTUVUQSBvbiBhIGxvb3Ag ZGV2aWNlIHRyYW5zbGF0ZXMgdG8gYQo+IGZhbGxvY2F0ZSg8aW5zZXJ0IG1ldGEgZmxhZyBuYW1l PikgdG8gdGhlIHVuZGVybHlpbmcgZmlsZSk/CgpVbmNsZWFyLCBJIHdhcyB0aGlua2luZyB5b3Vy IFJFUV9VTlNIQVJFICh0aWVkIHRvIGZhbGxvY2F0ZSkgbWlnaHQgYmUKYSBtZWFucyB0byB0cmFu c2xhdGUgUkVRX09QX1BST1ZJU0lPTiArIFJFUV9NRVRBIHRvIGZhbGxvY2F0ZSBhbmQgaGF2ZQpp dCBwZXJmb3JtIHRoZSBMQkEtc3BlY2lmaWMgcHJvdmlzaW9uaW5nIG9mIEpvZSdzIGRlc2lnbiAo cmVmZXJlbmNlZApiZWxvdykuCgo+IDxiaWtlc2hlZD4KPiBJIHRoaW5rIHRoYXQgbWlnaHQgaGF2 ZSBhcHBsaWNhdGlvbnMgYmV5b25kIGp1c3QgcHJvdmlzaW9uaW5nOgo+IGN1cnJlbnRseSwgZm9y IHN0YWNrZWQgZmlsZXN5c3RlbXMgKGVnIGZpbGVzeXN0ZW1zIHJlc2lkaW5nIGluIGEgZmlsZQo+ IG9uIHRvcCBvZiBhbm90aGVyIGZpbGVzeXN0ZW0pLCBldmVuIGlmIHRoZSB1cHBlciBmaWxlc3lz dGVtIGlzc3Vlcwo+IHJlYWQvd3JpdGUgcmVxdWVzdHMgd2l0aCBSRVFfTUVUQSB8IFJFUV9QUklP LCB0aGVzZSBmbGFncyBhcmUgbG9zdCBpbgo+IHRyYW5zbGF0aW9uIGF0IHRoZSBsb29wIGRldmlj ZSBsYXllci4gIEEgZmxhZyBsaWtlIHRoZSBhYm92ZSB3b3VsZAo+IGFsbG93IHRoZSBwcmlvcml0 aXphdGlvbiBvZiBzdGFja2VkIGZpbGVzeXN0ZW0gbWV0YWRhdGEgcmVxdWVzdHMuCj4gPC9iaWtl c2hlZD4KClllcywgaXQgY291bGQgcHJvdmUgdXNlZnVsLgoKPiBCcmluZ2luZyB0aGUgZGlzY3Vz c2lvbiBiYWNrIHRvIHRoaXMgc2VyaWVzIGZvciBhIGJpdCwgSSdtIHN0aWxsCj4gd2FpdGluZyBv biBmZWVkYmFjayBmcm9tIHRoZSBCbG9jayBtYWludGFpbmVycyBiZWZvcmUgc2VuZGluZyBvdXQg djgKPiAod2hpY2ggYXQgdGhlIG1vbWVudCwgb25seSBoYXZlIGEKPiBzL0VYUE9SVF9TWU1CT0wv RVhQT1JUX1NZTUJPTF9HUEwvZykuIEkgYmVsaWV2ZSBmcm9tIHRoZSBjb252ZXJzYXRpb24KPiBt b3N0IG9mIHRoZSBhYm92ZSBpcyBmb2xsb3cgdXAgd29yaywgYnV0IHBsZWFzZSBsZXQgbWUga25v dyBpZiB5b3UnZAo+IHByZWZlciBJIGFkZCBzb21lIG9mIHRoaXMgdG8gdGhlIGN1cnJlbnQgc2Vy aWVzIQoKSSBuZWVkIGEgYml0IG1vcmUgdGltZSB0byB3b3JrIHRocm91Z2ggdmFyaW91cyBhc3Bl Y3RzIG9mIHRoZSBicm9hZGVyCnJlcXVpcmVtZW50cyBhbmQgdGhlIHJlc3VsdGluZyBpbnRlcmZh Y2VzIHRoYXQgZmFsbCBvdXQuCgpKb2UncyBkZXNpZ24gaXMgcHJldHR5IGNvbXBlbGxpbmcgYmVj YXVzZSBpdCB3aWxsIHByb3Blcmx5IGhhbmRsZQpzbmFwc2hvdCB0aGluIGRldmljZXM6Cmh0dHBz Oi8vbGlzdG1hbi5yZWRoYXQuY29tL2FyY2hpdmVzL2RtLWRldmVsLzIwMjMtTWF5LzA1NDM1MS5o dG1sCgpIZXJlIGlzIG15IGxhdGVzdCBzdGF0dXM6Ci0gRm9jdXNlZCBvbiBwcm90b3R5cGUgZm9y IHRoaW5wIGJsb2NrIHJlc2VydmF0aW9uIChYRlMgbWV0YWRhdGEsIFhGUwogIGRlbGFsbG9jLCBm YWxsb2NhdGUpCi0gRGVjaWRlZCB0aGUgImR5bmFtaWMiIChub24tTEJBIHNwZWNpZmljKSByZXNl cnZhdGlvbiBzdHVmZiAob2xkCiAgcHJvdG90eXBlIGNvZGUpIGlzIGJlc3QgbGVmdCBpbmRlcGVu ZGVudCBmcm9tIEpvZSdzIGRlc2lnbi4gIFNPIDIKICBjbGFzc2VzIG9mIHRoaW5wIHJlc2VydmF0 aW9uLgogIC0gRm9yd2FyZC1wb3J0ZWQgdGhlIG9sZCBwcm90b3R5cGUgY29kZSB0aGF0IEJyaWFu IEZvc3RlciwgSm9lCiAgICBUaG9ybmJlciBhbmQgSSB3b3JrZWQgb24geWVhcnMgYWdvLiAgSXQg bmVlZHMgbW9yZSBjYXJlZnVsIHJldmlldwogICAgKGFuZCB2ZXJ5IGxpa2VseSB3aWxsIG5lZWQg Zml4ZXMgZnJvbSBCcmlhbiBhbmQgbXlzZWxmKS4gIFRoZSBYRlMKICAgIGNoYW5nZXMgYXJlIHBy ZXR0eSBpbnRydXNpdmUgYW5kIGxpa2VseSB1cCBmb3Igc2VyaW91cyBkZWJhdGUgKGFzCiAgICB0 byB3aGV0aGVyIHdlIGV2ZW4gY2FyZSB0byBoYW5kbGUgcmVzZXJ2YXRpb25zIGZvciB1c2VyIGRh dGEpLgotIFJFUV9PUF9QUk9WSVNJT04gYmlv4oCZcyB3aXRoIFJFUV9NRVRBIHdpbGwgdXNlIEpv ZeKAmXMgZGVzaWduLAogIG90aGVyd2lzZSBkYXRhIChYRlMgZGF0YSBhbmQgZmFsbG9jYXRlKSB3 aWxsIHVzZSDigJxkeW5hbWlj4oCdCiAgcmVzZXJ2YXRpb24uCiAgLSAiZHluYW1pYyIgbmFtZSBp cyBkdWUgdG8gdGhlIHJlc2VydmF0aW9uIGJlaW5nIGdlbmVyaWMgKG5vbi1MQkE6CiAgICBub3Qg aW4gdGVybXMgb2YgYW4gTEJBIHJhbmdlKS4gQWxzbywgaW4tY29yZSBvbmx5OyBzbyB0aGUgYXNz b2NpYXRlZAogICAg4oCcZHluYW1pY19yZXNlcnZlX2NvdW504oCdIGFjY291bnRpbmcgaXMgcmVz ZXQgdG8gMCBldmVyeSBhY3RpdmF0aW9uLiAKICAtIEZhbGxvY2F0ZSBtYXkgcmVxdWlyZSBzdHJv bmdlciBndWFyYW50ZWVzIGluIHRoZSBlbmQgKGluIHdoaWNoCiAgICBjYXNlIHdl4oCZbGwgYWRk IGEgUkVRX1VOU0hBUkUgZmxhZyB0aGF0IGlzIHNlbGVjdGFibGUgZnJvbSB0aGUKICAgIGZhbGxv Y2F0ZSBpbnRlcmZhY2UpIAotIFdpbGwgdHJ5IHRvIHNoYXJlIGNvbW1vbiBjb2RlLCBidXQganVz dCBzb3J0aW5nIG91dCBoaWdobGV2ZWwKICBpbnRlcmZhY2Uocykgc3RpbGwuLi4KCkknbGwgdHJ5 IHRvIGdldCBhIGdpdCB0cmVlIHRvZ2V0aGVyIGVhcmx5IG5leHQgd2Vlay4gIEl0IHdpbGwgYmUg dGhlCmZvcndhcmQgcG9ydGVkICJkeW5hbWljIiBwcm90b3R5cGUgY29kZSBhbmQgeW91ciBsYXRl c3QgdjcgY29kZSB3aXRoCnNvbWUgYWRkaXRpb25hbCB3b3JrIHRvIGJyYW5jaCBhY2NvcmRpbmds eSBmb3IgZWFjaCBjbGFzcyBvZiB0aGlucApyZXNlcnZhdGlvbi4gIEFuZCBJJ2xsIHVzZSB5b3Vy IHY3IGNvZGUgYXMgYSBjcnVkZSBzdHViIGZvciBKb2UncwphcHByb2FjaCAoYnJhbmNoIHRha2Vu IGlmIFJFUV9NRVRBIHNldCkuCgpMYXN0bHksIGhlcmUgYXJlIHNvbWUgYWRkaXRpb25hbCBUT0RP cyBJJ3ZlIG5vdGVkIGluIGNvZGUgZWFybGllciBpbgpteSByZXZpZXcgcHJvY2VzczoKCmRpZmYg LS1naXQgYS9kcml2ZXJzL21kL2RtLXRoaW4uYyBiL2RyaXZlcnMvbWQvZG0tdGhpbi5jCmluZGV4 IDBkOTMwMTgwMjYwOS4uNDNhNjcwMmY5ZWZlIDEwMDY0NAotLS0gYS9kcml2ZXJzL21kL2RtLXRo aW4uYworKysgYi9kcml2ZXJzL21kL2RtLXRoaW4uYwpAQCAtMTk2NCw2ICsxOTY0LDI2IEBAIHN0 YXRpYyB2b2lkIHByb2Nlc3NfcHJvdmlzaW9uX2JpbyhzdHJ1Y3QgdGhpbl9jICp0Yywgc3RydWN0 IGJpbyAqYmlvKQogCXN0cnVjdCBkbV9jZWxsX2tleSBrZXk7CiAJc3RydWN0IGRtX3RoaW5fbG9v a3VwX3Jlc3VsdCBsb29rdXBfcmVzdWx0OwogCisJLyoKKwkgKiBGSVhNRToKKwkgKiBKb2UncyBl bGVnYW50IHJlc2VydmF0aW9uIGRlc2lnbiBpcyBkZXRhaWxlZCBoZXJlOgorCSAqIGh0dHBzOi8v bGlzdG1hbi5yZWRoYXQuY29tL2FyY2hpdmVzL2RtLWRldmVsLzIwMjMtTWF5LzA1NDM1MS5odG1s CisJICogLSB0aGlzIGRlc2lnbiwgd2l0aCBhc3NvY2lhdGVkIHRoaW5wIG1ldGFkYXRhIHVwZGF0 ZXMsCisJICogICBpcyBob3cgcHJvdmlzaW9uIGJpb3Mgc2hvdWxkIGJlIGhhbmRsZWQuCisJICoK KwkgKiBGSVhNRTogYWRkIHRoaW4tcG9vbCBmbGFnICJpZ25vcmVfcHJvdmlzaW9uIgorCSAqCisJ ICogRklYTUU6IG5lZWRzIHByb3Zpc2lvbl9wYXNzZG93biBzdXBwb3J0CisJICogICAgICAgIChu ZWVkcyB0aGlucCBmbGFnICJub19wcm92aXNpb25fcGFzc2Rvd24iKQorCSAqLworCisJLyoKKwkg KiBGSVhNRTogcmVxdWlyZSBSRVFfTUVUQSAob3IgUkVRX1VOU0hBUkU/KSB0byBhbGxvdyBkZWVw ZXIKKwkgKiAgICAgICAgcHJvdmlzaW9uaW5nIGNvZGUgdGhhdCBmb2xsb3dzPyAoc28gdGhhdCB0 aGlucAorCSAqICAgICAgICBibG9jayBfaXNfIGZ1bGx5IHByb3Zpc2lvbmVkIHVwb24gcmV0dXJu KQorCSAqICAgICAgICAob3IganVzdCByZW1vdmUgYWxsIGJlbG93IGNvZGUgZW50aXJlbHk/KQor CSAqLworCiAJLyoKIAkgKiBJZiBjZWxsIGlzIGFscmVhZHkgb2NjdXBpZWQsIHRoZW4gdGhlIGJs b2NrIGlzIGFscmVhZHkKIAkgKiBiZWluZyBwcm92aXNpb25lZCBzbyB3ZSBoYXZlIG5vdGhpbmcg ZnVydGhlciB0byBkbyBoZXJlLgoKLS0KZG0tZGV2ZWwgbWFpbGluZyBsaXN0CmRtLWRldmVsQHJl ZGhhdC5jb20KaHR0cHM6Ly9saXN0bWFuLnJlZGhhdC5jb20vbWFpbG1hbi9saXN0aW5mby9kbS1k ZXZlbAo= 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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94BF4C7EE29 for ; Fri, 2 Jun 2023 21:53:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236643AbjFBVxU (ORCPT ); Fri, 2 Jun 2023 17:53:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50366 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236623AbjFBVxN (ORCPT ); Fri, 2 Jun 2023 17:53:13 -0400 Received: from mail-qk1-f182.google.com (mail-qk1-f182.google.com [209.85.222.182]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CDAEB10E3 for ; Fri, 2 Jun 2023 14:52:03 -0700 (PDT) Received: by mail-qk1-f182.google.com with SMTP id af79cd13be357-75ca95cd9b1so271368885a.0 for ; Fri, 02 Jun 2023 14:52:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685742652; x=1688334652; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UTRky113EniM0nT/xznU7UrijnGVH8CEk6F86K/tnEo=; b=hW+9e595C4NDNo3OGS03LoR7HP6xc3GDqOrAFXu6dZLZPs5fcGjHazkCt7IzrIerog 4FwGftlHdO+MNplAoIrYa3IVu8/yfVnQUvJ8NfdpgY/o5YnGfjUFehI6L9YOnAMVRd1o D8L1zc/114eFIDUsi99jRhsJ562YNF3RV3hag3Y7nLW/9XMFLesNtAgHoR/gi5+za5pD cuuKqMd+feQef1hvwZPPMRPC7On9QmMJCDxtPz7FHpt0yCzktHibiTDacQX3AAxUNUVa TgV82Kwkg61eFnUmNYUNfkjTZKKZGqg2D02RgBMJtQfQu37Fvh9GEgWlJjz/C9jRBw7N 1A0g== X-Gm-Message-State: AC+VfDwSWE/Oqg28vQY9XG+o4JXTOU/fWc7gAuiSi1jqf14t1vBejxUV G1RbsE5fqTIgoKyXP0IquWKEQA9oBdZJBtvUwA== X-Google-Smtp-Source: ACHHUZ7EYtrupkurG9n+8SFwQbMMRsCnns2grd76F2kWxvjetuxx5d1DqIPs4GPppwGqt5TFKDjmsg== X-Received: by 2002:ac8:5e11:0:b0:3f6:b017:6289 with SMTP id h17-20020ac85e11000000b003f6b0176289mr16977166qtx.10.1685742651495; Fri, 02 Jun 2023 14:50:51 -0700 (PDT) Received: from localhost (pool-68-160-166-30.bstnma.fios.verizon.net. [68.160.166.30]) by smtp.gmail.com with ESMTPSA id i2-20020ac813c2000000b003f6f83de87esm1236527qtj.92.2023.06.02.14.50.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Jun 2023 14:50:50 -0700 (PDT) Date: Fri, 2 Jun 2023 17:50:49 -0400 From: Mike Snitzer To: Sarthak Kukreti Cc: Jens Axboe , linux-block@vger.kernel.org, Joe Thornber , "Michael S. Tsirkin" , Jason Wang , "Darrick J. Wong" , Brian Foster , Bart Van Assche , Dave Chinner , linux-kernel@vger.kernel.org, Christoph Hellwig , dm-devel@redhat.com, Andreas Dilger , Stefan Hajnoczi , linux-fsdevel@vger.kernel.org, Theodore Ts'o , linux-ext4@vger.kernel.org, Joe Thornber , Alasdair Kergon Subject: Re: [PATCH v7 0/5] Introduce provisioning primitives Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Fri, Jun 02 2023 at 2:44P -0400, Sarthak Kukreti wrote: > On Tue, May 30, 2023 at 8:28 AM Mike Snitzer wrote: > > > > On Tue, May 30 2023 at 10:55P -0400, > > Joe Thornber wrote: > > > > > On Tue, May 30, 2023 at 3:02 PM Mike Snitzer wrote: > > > > > > > > > > > Also Joe, for you proposed dm-thinp design where you distinquish > > > > between "provision" and "reserve": Would it make sense for REQ_META > > > > (e.g. all XFS metadata) with REQ_PROVISION to be treated as an > > > > LBA-specific hard request? Whereas REQ_PROVISION on its own provides > > > > more freedom to just reserve the length of blocks? (e.g. for XFS > > > > delalloc where LBA range is unknown, but dm-thinp can be asked to > > > > reserve space to accomodate it). > > > > > > > > > > My proposal only involves 'reserve'. Provisioning will be done as part of > > > the usual io path. > > > > OK, I think we'd do well to pin down the top-level block interfaces in > > question. Because this patchset's block interface patch (2/5) header > > says: > > > > "This patch also adds the capability to call fallocate() in mode 0 > > on block devices, which will send REQ_OP_PROVISION to the block > > device for the specified range," > > > > So it wires up blkdev_fallocate() to call blkdev_issue_provision(). A > > user of XFS could then use fallocate() for user data -- which would > > cause thinp's reserve to _not_ be used for critical metadata. > > > > The only way to distinquish the caller (between on-behalf of user data > > vs XFS metadata) would be REQ_META? > > > > So should dm-thinp have a REQ_META-based distinction? Or just treat > > all REQ_OP_PROVISION the same? > > > I'm in favor of a REQ_META-based distinction. Does that imply that > REQ_META also needs to be passed through the block/filesystem stack > (eg. REQ_OP_PROVION + REQ_META on a loop device translates to a > fallocate() to the underlying file)? Unclear, I was thinking your REQ_UNSHARE (tied to fallocate) might be a means to translate REQ_OP_PROVISION + REQ_META to fallocate and have it perform the LBA-specific provisioning of Joe's design (referenced below). > > I think that might have applications beyond just provisioning: > currently, for stacked filesystems (eg filesystems residing in a file > on top of another filesystem), even if the upper filesystem issues > read/write requests with REQ_META | REQ_PRIO, these flags are lost in > translation at the loop device layer. A flag like the above would > allow the prioritization of stacked filesystem metadata requests. > Yes, it could prove useful. > Bringing the discussion back to this series for a bit, I'm still > waiting on feedback from the Block maintainers before sending out v8 > (which at the moment, only have a > s/EXPORT_SYMBOL/EXPORT_SYMBOL_GPL/g). I believe from the conversation > most of the above is follow up work, but please let me know if you'd > prefer I add some of this to the current series! I need a bit more time to work through various aspects of the broader requirements and the resulting interfaces that fall out. Joe's design is pretty compelling because it will properly handle snapshot thin devices: https://listman.redhat.com/archives/dm-devel/2023-May/054351.html Here is my latest status: - Focused on prototype for thinp block reservation (XFS metadata, XFS delalloc, fallocate) - Decided the "dynamic" (non-LBA specific) reservation stuff (old prototype code) is best left independent from Joe's design. SO 2 classes of thinp reservation. - Forward-ported the old prototype code that Brian Foster, Joe Thornber and I worked on years ago. It needs more careful review (and very likely will need fixes from Brian and myself). The XFS changes are pretty intrusive and likely up for serious debate (as to whether we even care to handle reservations for user data). - REQ_OP_PROVISION bio’s with REQ_META will use Joe’s design, otherwise data (XFS data and fallocate) will use “dynamic” reservation. - "dynamic" name is due to the reservation being generic (non-LBA: not in terms of an LBA range). Also, in-core only; so the associated “dynamic_reserve_count” accounting is reset to 0 every activation. - Fallocate may require stronger guarantees in the end (in which case we’ll add a REQ_UNSHARE flag that is selectable from the fallocate interface) - Will try to share common code, but just sorting out highlevel interface(s) still... I'll try to get a git tree together early next week. It will be the forward ported "dynamic" prototype code and your latest v7 code with some additional work to branch accordingly for each class of thinp reservation. And I'll use your v7 code as a crude stub for Joe's approach (branch taken if REQ_META set). Lastly, here are some additional TODOs I've noted in code earlier in my review process: diff --git a/drivers/md/dm-thin.c b/drivers/md/dm-thin.c index 0d9301802609..43a6702f9efe 100644 --- a/drivers/md/dm-thin.c +++ b/drivers/md/dm-thin.c @@ -1964,6 +1964,26 @@ static void process_provision_bio(struct thin_c *tc, struct bio *bio) struct dm_cell_key key; struct dm_thin_lookup_result lookup_result; + /* + * FIXME: + * Joe's elegant reservation design is detailed here: + * https://listman.redhat.com/archives/dm-devel/2023-May/054351.html + * - this design, with associated thinp metadata updates, + * is how provision bios should be handled. + * + * FIXME: add thin-pool flag "ignore_provision" + * + * FIXME: needs provision_passdown support + * (needs thinp flag "no_provision_passdown") + */ + + /* + * FIXME: require REQ_META (or REQ_UNSHARE?) to allow deeper + * provisioning code that follows? (so that thinp + * block _is_ fully provisioned upon return) + * (or just remove all below code entirely?) + */ + /* * If cell is already occupied, then the block is already * being provisioned so we have nothing further to do here.