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 98708C433F5 for ; Tue, 4 Oct 2022 18:27:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1664908021; 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=HGMmDlRUPEh+kLmKhcxb5tSsAlO3fvWVOylnRIKZzGs=; b=HT7Rz2qqJnnUQfXEEmjvl+eGvdcwnGcr73vQeYNfZv7qe6sFjXKDS2U+qAx+oH2jRZFrij 368WC2Q0Zql7IgGey4OW5wpNrW52zbZkEr9q5KaWgco8lWNpvRj3ugBkGjDqGFwnhegg7v E+JUUH3FAJ4zNawkF8k53gSr+VbDklA= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-452-Cpiqac3PPRCHgRVHNnFR_g-1; Tue, 04 Oct 2022 14:26:57 -0400 X-MC-Unique: Cpiqac3PPRCHgRVHNnFR_g-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 2BE34185A7A3; Tue, 4 Oct 2022 18:26: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 E435D4A927A; Tue, 4 Oct 2022 18:26:51 +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 BBF1B1946A4F; Tue, 4 Oct 2022 18:26:50 +0000 (UTC) Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) by mm-prod-listman-01.mail-001.prod.us-east-1.aws.redhat.com (Postfix) with ESMTP id 4C65F1946A4C for ; Tue, 4 Oct 2022 18:26:49 +0000 (UTC) Received: by smtp.corp.redhat.com (Postfix) id 2E34A49BB66; Tue, 4 Oct 2022 18:26:49 +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 273CD49BB64 for ; Tue, 4 Oct 2022 18:26:48 +0000 (UTC) Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (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 83C423C025A2 for ; Tue, 4 Oct 2022 18:26:48 +0000 (UTC) Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-37-3CwpsS8bM1KSmUjZOr8DIw-1; Tue, 04 Oct 2022 14:26:46 -0400 X-MC-Unique: 3CwpsS8bM1KSmUjZOr8DIw-1 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 1AFCEB81B5D; Tue, 4 Oct 2022 18:26:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B470EC433D6; Tue, 4 Oct 2022 18:26:43 +0000 (UTC) Date: Tue, 4 Oct 2022 11:26:43 -0700 From: "Darrick J. Wong" To: =?utf-8?B?R290b3UsIFlhc3Vub3JpL+S6lOWztiDlurfmloc=?= Message-ID: References: <7fdc9e88-f255-6edb-7964-a5a82e9b1292@fujitsu.com> <76ea04b4-bad7-8cb3-d2c6-4ad49def4e05@fujitsu.com> <1444b9b5-363a-163c-0513-55d1ea951799@fujitsu.com> MIME-Version: 1.0 In-Reply-To: X-Mimecast-Impersonation-Protect: Policy=CLT - Impersonation Protection Definition; Similar Internal Domain=false; Similar Monitored External Domain=false; Custom External Domain=false; Mimecast External Domain=false; Newly Observed Domain=false; Internal User Name=false; Custom Display Name List=false; Reply-to Address Mismatch=false; Targeted Threat Dictionary=false; Mimecast Threat Dictionary=false; Custom Threat Dictionary=false X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 Subject: Re: [dm-devel] [PATCH] xfs: fail dax mount if reflink is enabled on a partition 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: "linux-xfs@vger.kernel.org" , toshi.kani@hpe.com, dm-devel@redhat.com, "nvdimm@lists.linux.dev" , Brian Foster , =?utf-8?B?WWFuZywgWGlhby/mnagg5pmT?= , "david@fromorbit.com" , "linux-kernel@vger.kernel.org" , =?utf-8?B?UnVhbiwgU2hpeWFuZy/pmK4g5LiW6Ziz?= , "hch@infradead.org" , Jeff Moyer , zwisler@kernel.org, "linux-fsdevel@vger.kernel.org" Errors-To: dm-devel-bounces@redhat.com Sender: "dm-devel" X-Scanned-By: MIMEDefang 3.1 on 10.11.54.9 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gTW9uLCBPY3QgMDMsIDIwMjIgYXQgMDk6MTI6NDZQTSAtMDcwMCwgR290b3UsIFlhc3Vub3Jp L+S6lOWztiDlurfmlocgd3JvdGU6Cj4gT24gMjAyMi8xMC8wMyAxNzoxMiwgRGFycmljayBKLiBX b25nIHdyb3RlOgo+ID4gT24gRnJpLCBTZXAgMzAsIDIwMjIgYXQgMDk6NTY6NDFBTSArMDkwMCwg R290b3UsIFlhc3Vub3JpL+S6lOWztiDlurfmlocgd3JvdGU6Cj4gPiA+IEhlbGxvIGV2ZXJ5b25l LAo+ID4gPiAKPiA+ID4gT24gMjAyMi8wOS8yMCAxMTozOCwgWWFuZywgWGlhby/mnagg5pmTIHdy b3RlOgo+ID4gPiA+IEhpIERhcnJpY2ssIEJyaWFuIGFuZCBDaHJpc3RvcGgKPiA+ID4gPiAKPiA+ ID4gPiBQaW5nLiBJIGhvcGUgdG8gZ2V0IHlvdXIgZmVlZGJhY2suCj4gPiA+ID4gCj4gPiA+ID4g MSkgSSBoYXZlIGNvbmZpcm1lZCB0aGF0IHRoZSBmb2xsb3dpbmcgcGF0Y2ggc2V0IGRpZCBub3Qg Y2hhbmdlIHRoZSB0ZXN0Cj4gPiA+ID4gcmVzdWx0IG9mIGdlbmVyaWMvNDcwIHdpdGggdGhpbi12 b2x1bWUuIEJlc2lkZXMsIEkgZGlkbid0IHNlZSBhbnkKPiA+ID4gPiBmYWlsdXJlIHdoZW4gcnVu bmluZyBnZW5lcmljLzQ3MCBiYXNlZCBvbiBub3JtYWwgUE1FTSBkZXZpY2UgaW5zdGFlZCBvZgo+ ID4gPiA+IHRoaW4tdm9sdW1lLgo+ID4gPiA+IGh0dHBzOi8vbG9yZS5rZXJuZWwub3JnL2xpbnV4 LXhmcy8yMDIxMTEyOTEwMjIwMy4yMjQzNTA5LTEtaGNoQGxzdC5kZS8KPiA+ID4gPiAKPiA+ID4g PiAyKSBJIGNhbiByZXByb2R1Y2UgdGhlIGZhaWx1cmUgb2YgZ2VuZXJpYy80ODIgd2l0aG91dCB0 aGluLXZvbHVtZS4KPiA+ID4gPiAKPiA+ID4gPiAzKSBJcyBpdCBuZWNlc3NhcnkgdG8gbWFrZSB0 aGluLXZvbHVtZSBzdXBwb3J0IERBWC4gSXMgdGhlcmUgYW55IHVzZQo+ID4gPiA+IGNhc2UgZm9y IHRoZSByZXF1aXJlbWVudD8KPiA+ID4gCj4gPiA+IAo+ID4gPiBUaG91Z2ggSSBhc2tlZCBvdGhl ciBwbGFjZSgqKSwgSSByZWFsbHkgd2FudCB0byBrbm93IHRoZSB1c2VjYXNlIG9mCj4gPiA+IGRt LXRoaW4tdm9sdW1lIHdpdGggREFYIGFuZCByZWZsaW5rLgo+ID4gPiAKPiA+ID4gCj4gPiA+IElu IG15IHVuZGVyc3RhbmRpbmcsIGRtLXRoaW4tdm9sdW1lIHNlZW1zIHRvIHByb3ZpZGUgc2ltaWxh ciBmZWF0dXJlIGxpa2UKPiA+ID4gcmVmbGluayBvZiB4ZnMuIEJvdGggZmVhdHVyZSBwcm92aWRl IENPVyB1cGRhdGUgdG8gcmVkdWNlIHVzYWdlIG9mCj4gPiA+IGl0cyByZWdpb24sIGFuZCBzbmFw c2hvdCBmZWF0dXJlLCByaWdodD8KPiA+ID4gCj4gPiA+IEkgZm91bmQgdGhhdCBkb2NrZXIgc2Vl bXMgdG8gc2VsZWN0IG9uZSBvZiB0aGVtIChvciBvdGhlciBmZWF0dXJlIHdoaWNoCj4gPiA+IHN1 cHBvcnRzIENPVykuIFRoZW4gdXNlciBkb24ndCBuZWVkIHRvIHVzZSB0aGluLXZvbHVtZSBhbmQg cmVmbGluayBhdCBzYW1lCj4gPiA+IHRpbWUuCj4gPiA+IAo+ID4gPiBEYXRhYmFzZSB3aGljaCB1 c2VzIEZTLURBWCBtYXkgd2FudCB0byB1c2Ugc25hcHNob3QgZm9yIGl0cyBkYXRhIG9mIEZTLURB WCwKPiA+ID4gaXRzIHVzZXIgc2VlbXMgdG8gYmUgc2F0aXNmaWVkIHdpdGggcmVmbGluayBvciB0 aGluLXZvbHVtZS4KPiA+ID4gCj4gPiA+IFNvIEkgY291bGQgbm90IGZpbmQgb24gd2hhdCB1c2Ut Y2FzZSB1c2VyIHdvdWxkIGxpa2UgdG8gdXNlIGRtLXRoaW4tdm9sdW1lCj4gPiA+IGFuZCByZWZs aW5rIGF0IHNhbWUgdGltZS4KPiA+ID4gCj4gPiA+IFRoZSBvbmx5IHBvc3NpYmlsaXR5IGlzIHRo YXQgdGhlIHVzZXIgaGFzIG1pc3Rha2VubHkgY29uZmlndXJlZCBkbS10aGlucG9vbAo+ID4gPiBh bmQgcmVmbGluayB0byBiZSB1c2VkIGF0IHRoZSBzYW1lIHRpbWUsIGJ1dCBpZiB0aGF0IGlzIHRo ZSBjYXNlLCBpdCBzZWVtcwo+ID4gPiB0byBiZSBiZXR0ZXIgZm9yIHRoZSB1c2VyIHRvIGRpc2Fi bGUgb25lIG9yIHRoZSBvdGhlci4KPiA+ID4gCj4gPiA+IEkgcmVhbGx5IHdhbmRlciB3aHkgZG0t dGhpbi12b2x1bWUgbXVzdCBiZSB1c2VkIHdpdGggcmVmbGlrIGFuZCBGUy1EQVguCj4gPiAKPiA+ IFRoZXJlIGlzbid0IGEgaGFyZCByZXF1aXJlbWVudCBiZXR3ZWVuIGZzZGF4IGFuZCBkbS10aGlu cC4gIFRoZSAvdGVzdC8KPiA+IG5lZWRzIGRtLWxvZ3dyaXRlcyB0byBjaGVjayB0aGF0IHdyaXRl IHBhZ2UgZmF1bHRzIG9uIGEgTUFQX1NZTkMKPiA+IG1tYXBwaW5nIGFyZSBwZXJzaXN0ZWQgZGly ZWN0bHkgdG8gZGlzay4gIGRtLWxvZ3dyaXRlcyByZXF1aXJlcyBhIGZhc3QKPiA+IHdheSB0byB6 ZXJvIGFuIGVudGlyZSBkZXZpY2UgZm9yIGNvcnJlY3Qgb3BlcmF0aW9uIG9mIHRoZSByZXBsYXkg c3RlcCwKPiA+IGFuZCB0aGlucCBpcyB0aGUgb25seSB3YXkgdG8gZ3VhcmFudGVlIHRoYXQuCj4g Cj4gVGhhbmsgeW91IGZvciB5b3VyIGFuc3dlci4gQnV0IEkgc3RpbGwgZmVlbCBzb21ldGhpbmcg aXMgc3RyYW5nZS4KPiBUaG91Z2ggZG0tdGhpbnAgbWF5IGJlIGdvb2Qgd2F5IHRvIGV4ZWN1dGUg dGhlIHRlc3QgY29ycmVjdGx5LAoKWWVwLgoKPiBJIHN1cHBvc2UgaXQgc2VlbXMgdG8gYmUgbGlr ZWx5IGEga2luZCBvZiB3b3JrYXJvdW5kIHRvIHBhc3MgdGhlIHRlc3QsCj4gaXQgbWF5IG5vdCBi ZSByZWFsbHkgcmVxdWlyZWQgZm9yIGFjdHVhbCB1c2Vycy4KCkV4YWN0bHkgY29ycmVjdC4gIFJl YWwgdXNlcnMgc2hvdWxkIC9uZXZlci8gc2V0IHVwIHRoaXMga2luZCBvZiAodGVzdApzY2FmZm9s ZGluZ3xpbnNhbml0eSkgdG8gdXNlIGZzZGF4LgoKPiBDb3VsZCB5b3UgdGVsbCBtZSB3aHkgcGFz c2luZyB0ZXN0IGJ5IHdvcmthcm91bmQgaXMgc28gbmVjZXNzYXJ5PwoKTm90aWNlIHRoaXMgbGlu ZSBpbiBnZW5lcmljLzQ3MDoKCiRYRlNfSU9fUFJPRyAtdCAtYyAidHJ1bmNhdGUgJExFTiIgLWMg Im1tYXAgLVMgMCAkTEVOIiAtYyAibXdyaXRlIDAgJExFTiIgXAoJLWMgImxvZ193cml0ZXMgLWQg JExPR1dSSVRFU19OQU1FIC1tIHByZXVubWFwIiBcCgktZiAkU0NSQVRDSF9NTlQvdGVzdAoKVGhl IHNlY29uZCB4ZnNfaW8gY29tbWFuZCBjcmVhdGVzIGEgTUFQX1NZTkMgbW1hcCBvZiB0aGUKU0NS QVRDSF9NTlQvdGVzdCBmaWxlLCBhbmQgdGhlIHRoaXJkIGNvbW1hbmQgbWVtY3B5J3MgYnl0ZXMg dG8gdGhlCm1hcHBpbmcgdG8gaW52b2tlIHRoZSB3cml0ZSBwYWdlIGZhdWx0IGhhbmRsZXIuCgpU aGUgZm91cnRoIGNvbW1hbmQgdGVsbHMgdGhlIGRtLWxvZ3dyaXRlcyBkcml2ZXIgZm9yICRMT0dX UklURVNfTkFNRQooYWthIHRoZSBibG9jayBkZXZpY2UgY29udGFpbmluZyB0aGUgbW91bnRlZCBY RlMgZmlsZXN5c3RlbSkgdG8gY3JlYXRlIGEKbWFyayBjYWxsZWQgInByZXVubWFwIi4gIFRoaXMg bWFyayBjYXB0dXJlcyB0aGUgZXhhY3Qgc3RhdGUgb2YgdGhlIGJsb2NrCmRldmljZSBpbW1lZGlh dGVseSBhZnRlciB0aGUgd3JpdGUgZmF1bHRzIGNvbXBsZXRlLCBzbyB0aGF0IHdlIGNhbiBjb21l CmJhY2sgdG8gaXQgbGF0ZXIuICBUaGVyZSBhcmUgYSBmZXcgdGhpbmdzIHRvIG5vdGUgaGVyZToK CiAgKDEpIFdlIGRpZCBub3QgdGVsbCB0aGUgZnMgdG8gcGVyc2lzdCBhbnl0aGluZzsKICAoMikg V2UgY2FuJ3QgdXNlIGRtLXNuYXBzaG90IGhlcmUsIGJlY2F1c2UgZG0tc25hcHNob3Qgd2lsbCBm bHVzaCB0aGUKICAgICAgZnMgKEkgdGhpbms/KTsgYW5kCiAgKDMpIFRoZSBmcyBpcyBzdGlsbCBt b3VudGVkLCBzbyB0aGUgc3RhdGUgb2YgdGhlIGJsb2NrIGRldmljZSBhdCB0aGUKICAgICAgbWFy ayByZWZsZWN0cyBhIGRpcnR5IFhGUyB3aXRoIGEgbG9nIHRoYXQgbXVzdCBiZSByZXBsYXllZC4K ClRoZSBuZXh0IHRoaW5nIHRoZSB0ZXN0IGRvZXMgaXMgdW5tb3VudCB0aGUgZnMsIHJlbW92ZSB0 aGUgZG0tbG9nd3JpdGVzCmRyaXZlciB0byBzdG9wIHJlY29yZGluZywgYW5kIGNoZWNrIHRoZSBm czoKCl9sb2dfd3JpdGVzX3VubW91bnQKX2xvZ193cml0ZXNfcmVtb3ZlCl9kbXRoaW5fY2hlY2tf ZnMKClRoaXMgZW5zdXJlcyB0aGF0IHRoZSBwb3N0LXVtb3VudCBmcyBpcyBjb25zaXN0ZW50LiAg Tm93IHdlIHdhbnQgdG8gcm9sbApiYWNrIHRvIHRoZSBwbGFjZSB3ZSBtYXJrZWQgdG8gc2VlIGlm IHRoZSBtd3JpdGUgZGF0YSBtYWRlIGl0IHRvIHBtZW0uCkl0ICpzaG91bGQqIGhhdmUsIHNpbmNl IHdlIGFza2VkIGZvciBhIE1BUF9TWU5DIG1hcHBpbmcgb24gYSBmc2RheApmaWxlc3lzdGVtIHJl Y29yZGVkIG9uIGEgcG1lbSBkZXZpY2U6CgojIGNoZWNrIHByZS11bm1hcCBzdGF0ZQpfbG9nX3dy aXRlc19yZXBsYXlfbG9nIHByZXVubWFwICRETVRISU5fVk9MX0RFVgpfZG10aGluX21vdW50Cgpk bS1sb2d3cml0ZXMgY2FuJ3QgYWN0dWFsbHkgcm9sbCBiYWNrd2FyZHMgaW4gdGltZSB0byBhIG1h cmssIHNpbmNlIGl0Cm9ubHkgcmVjb3JkcyBuZXcgZGlzayBjb250ZW50cy4gIEl0IC9jYW4vIGhv d2V2ZXIgcm9sbCBmb3J3YXJkIGZyb20Kd2hhdGV2ZXIgcG9pbnQgaXQgYmVnYW4gcmVjb3JkaW5n IHdyaXRlcyB0byB0aGUgbWFyaywgc28gdGhhdCdzIHdoYXQgaXQKZG9lcy4KCkhvd2V2ZXIgLS0g cmVtZW1iZXIgbm90ZSAoMykgZnJvbSBlYXJsaWVyLiAgV2hlbiB3ZSBfZG10aGluX21vdW50IGFm dGVyCnJlcGxheWluZyB0aGUgbG9nIHRvIHRoZSAicHJldW5tYXAiIG1hcmssIFhGUyB3aWxsIHNl ZSB0aGUgZGlydHkgWEZTIGxvZwphbmQgdHJ5IHRvIHJlY292ZXIgdGhlIFhGUyBsb2cuICBUaGlz IGlzIHdoZXJlIHRoZSByZXBsYXkgcHJvYmxlbXMgY3JvcAp1cC4gIFRoZSBYRlMgbG9nIHJlY29y ZHMgYSBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmcgc2VxdWVuY2UgbnVtYmVyCihMU04pIHdpdGgg ZXZlcnkgbG9nIHVwZGF0ZSwgYW5kIHdoZW4gdXBkYXRlcyBhcmUgd3JpdHRlbiBpbnRvIHRoZQpm aWxlc3lzdGVtLCB0aGF0IExTTiBpcyBhbHNvIHdyaXR0ZW4gaW50byB0aGUgZmlsZXN5c3RlbSBi bG9jay4gIExvZwpyZWNvdmVyeSBhbHNvIHJlcGxheXMgdXBkYXRlcyBpbnRvIHRoZSBmaWxlc3lz dGVtLCBidXQgd2l0aCB0aGUgYWRkZWQKYmVoYXZpb3IgdGhhdCBpdCBza2lwcyBhIGJsb2NrIHJl cGxheSBpZiB0aGUgYmxvY2sncyBMU04gaXMgaGlnaGVyIHRoYW4KdGhlIHRyYW5zYWN0aW9uIGJl aW5nIHJlcGxheWVkLiAgSU9Xcywgd2UgbmV2ZXIgcmVwbGF5IG9sZGVyIGJsb2NrCmNvbnRlbnRz IG92ZXIgbmV3ZXIgYmxvY2sgY29udGVudHMuCgpGb3IgZG0tbG9nd3JpdGVzIHRoaXMgaXMgYSBt YWpvciBwcm9ibGVtLCBiZWNhdXNlIHRoZXJlIGNvdWxkIGJlIG1vcmUKZmlsZXN5c3RlbSB1cGRh dGVzIHdyaXR0ZW4gdG8gdGhlIFhGUyBsb2cgYWZ0ZXIgdGhlIG1hcmsgaXMgbWFkZS4gIExTTnMK d2lsbCB0aGVuIGJlIGhhbmRlZCBvdXQgbGlrZSB0aGlzOgoKbWtmc19sc24gICAgICAgICAgICAg ICAgIHByZXVubWFwX2xzbiAgICAgICAgICAgICB1bW91bnRfbHNuCiAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgfAogIHwtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLXx8LS0tLS0tLS0tLXwtLS0tLS0tLS0tLXwKICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8ICAgICAgICAgICB8CiAgICAgICAgICAgICAgICAgICAgICAgICB4eHhfbHNuICAg ICB5eXlfbHNuCgpMZXQncyBzYXkgdGhhdCBhIG5ldyBtZXRhZGF0YSBibG9jayAiQkJCIiB3YXMg Y3JlYXRlZCBpbiB1cGRhdGUgInh4eCIKaW1tZWRpYXRlbHkgYmVmb3JlIHRoZSBwcmV1bm1hcCBt YXJrIHdhcyBtYWRlLiAgUGVyICgxKSwgd2UgZGlkbid0IGZsdXNoCnRoZSBmaWxlc3lzdGVtIGJl Zm9yZSB0YWtpbmcgdGhlIG1hcmssIHdoaWNoIG1lYW5zIHRoYXQgdGhlIG5ldyBibG9jaydzCmNv bnRlbnRzIGV4aXN0IG9ubHkgaW4gdGhlIGxvZyBhdCB0aGlzIHBvaW50LgoKTGV0IHVzIGZ1cnRo ZXIgc2F5IHRoYXQgdGhlIG5ldyBibG9jayB3YXMgYWdhaW4gY2hhbmdlZCBpbiB1cGRhdGUgInl5 eSIsCndoZXJlIHByZXVubWFwX2xzbiA8IHl5eV9sc24gPD0gdW1vdW50X2xzbi4gIENsZWFybHks IHl5eV9sc24gPiB4eHhfbHNuLgp5eXlfbHNuIGlzIHdyaXR0ZW4gdG8gdGhlIGJsb2NrIGF0IHVu bW91bnQsIGJlY2F1c2UgdW5tb3VudGluZyBmbHVzaGVzCnRoZSBsb2cgY2xlYW4gYmVmb3JlIGl0 IGNvbXBsZXRlcy4gIFRoaXMgaXMgdGhlIGZpcnN0IHRpbWUgdGhhdCBCQkIgZXZlcgpnZXRzIHdy aXR0ZW4uCgpfbG9nX3dyaXRlc19yZXBsYXlfbG9nIGJlZ2lucyByZXBsYXlpbmcgdGhlIGJsb2Nr IGRldmljZSBmcm9tIG1rZnNfbHNuCnRvd2FyZHMgcHJldW5tYXBfbHNuLiAgV2hlbiBpdCdzIGRv bmUsIGl0IHdpbGwgaGF2ZSBhIGxvZyB0aGF0IHJlZmxlY3RzCmFsbCB0aGUgY2hhbmdlcyB1cCB0 byBwcmV1bm1hcF9sc24uICBSZWNhbGwgaG93ZXZlciB0aGF0IEJCQiBpc24ndAp3cml0dGVuIHVu dGlsIGFmdGVyIHRoZSBwcmV1bm1hcCBtYXJrLCB3aGljaCBtZWFucyB0aGF0IGRtLWxvZ3dyaXRl cyBoYXMKbm8gcmVjb3JkIG9mIEJCQiBiZWZvcmUgcHJldW5tYXBfbHNuLCBzbyBkbS1sb2d3cml0 ZXMgcmVwbGF5IHdvbid0IHRvdWNoCkJCQi4gIEF0IHRoaXMgcG9pbnQsIHRoZSBibG9jayBoZWFk ZXIgZm9yIEJCQiBoYXMgYSBVVUlEIHRoYXQgbWF0Y2hlcwp0aGUgZmlsZXN5c3RlbSwgYnV0IGEg TFNOICh5eXlfbHNuKSB0aGF0IGlzIGJleW9uZCBwcmV1bm1hcF9sc24uCgpYRlMgbG9nIHJlY292 ZXJ5IHN0YXJ0cyB1cCwgYW5kIGZpbmRzIHRyYW5zYWN0aW9uIHh4eC4gIEl0IHdpbGwgcmVhZCBC QkIKZnJvbSBkaXNrLCBidXQgdGhlbiBpdCB3aWxsIHNlZSB0aGF0IGl0IGhhcyBhbiBMU04gb2Yg eXl5X2xzbi4gIFRoaXMgaXMKbGFyZ2VyIHRoYW4geHh4X2xzbiwgc28gaXQgY29uY2x1ZGVzIHRo YXQgQkJCIGlzIG5ld2VyIHRoYW4gdGhlIGxvZyBhbmQKbW92ZXMgb24gdG8gdGhlIG5leHQgbG9n IGl0ZW0uICBObyBvdGhlciBsb2cgaXRlbXMgdG91Y2ggQkJCLCBzbwpyZWNvdmVyeSBmaW5pc2hl cywgYW5kIG5vdyB3ZSBoYXZlIGEgZmlsZXN5c3RlbSBjb250YWluaW5nIG9uZSBtZXRhZGF0YQpi bG9jayAoQkJCKSBmcm9tIHRoZSBmdXR1cmUuICBUaGlzIGlzIGFuIGluY29uc2lzdGVudCBmaWxl c3lzdGVtLCBhbmQKaGFzIGNhdXNlZCBmYWlsdXJlcyBpbiB0aGUgdGVzdHMgdGhhdCB1c2UgbG9n d3JpdGVzLgoKVG8gd29yayBhcm91bmQgdGhpcyBwcm9ibGVtLCBhbGwgd2UgcmVhbGx5IG5lZWQg dG8gZG8gaXMgcmVpbml0aWFsaXplCnRoZSBlbnRpcmUgYmxvY2sgZGV2aWNlIHRvIGtub3duIGNv bnRlbnRzIGF0IG1rZnMgdGltZS4gIFRoaXMgY2FuIGJlCmRvbmUgZXhwZW5zaXZlbHkgYnkgd3Jp dGluZyB6ZXJvZXMgdG8gdGhlIGVudGlyZSBibG9jayBkZXZpY2UsIG9yIGl0IGNhbgpiZSBkb25l IGNoZWFwbHkgYnkgKGEpIGlzc3VpbmcgRElTQ0FSRCB0byB0aGUgd2hvbGUgdGhlIGJsb2NrIGRl dmljZSBhdAp0aGUgc3RhcnQgb2YgdGhlIHRlc3QgYW5kIChiKSBlbnN1cmluZyB0aGF0IHJlYWRz IGFmdGVyIGEgZGlzY2FyZCBhbHdheXMKcHJvZHVjZSB6ZXJvZXMuICBta2ZzLnhmcyBhbHJlYWR5 IGRvZXMgKGEpLCBzbyB0aGUgdGVzdCBtZXJlbHkgaGFzIHRvCmVuc3VyZSAoYikuCgpkbS10aGlu cCBpcyB0aGUgb25seSBzb2Z0d2FyZSBzb2x1dGlvbiB0aGF0IHByb3ZpZGVzIChiKSwgc28gdGhh dCdzIHdoeQp0aGlzIHRlc3QgbGF5ZXJzIGRtLWxvZ3dyaXRlcyBvbiB0b3Agb2YgZG0tdGhpbnAg b24gdG9wIG9mICRTQ1JBVENIX0RFVi4KVGhpcyBjb21iaW5hdGlvbiB1c2VkIHRvIHdvcmssIGJ1 dCB3aXRoIHRoZSBwZW5kaW5nIHBtZW0vYmxvY2tkZXYKZGl2b3JjZSwgdGhpcyBzdHJhdGVneSBp cyBubyBsb25nZXIgZmVhc2libGUuCgpJIHRoaW5rIHRoZSBvbmx5IHdheSB0byBmaXggdGhpcyB0 ZXN0IGlzIChhKSByZXZlcnQgYWxsIG9mIENocmlzdG9waCdzCmNoYW5nZXMgc28gZmFyIGFuZCBz Y3V0dGxlIHRoZSBkaXZvcmNlOyBvciAoYikgY2hhbmdlIHRoaXMgdGVzdCBsaWtlIHNvOgoKIDEu IENyZWF0ZSBhIGxhcmdlIHNwYXJzZSBmaWxlIG9uICRURVNUX0RJUiBhbmQgbG9zZXR1cCB0aGF0 IHNwYXJzZQogICAgZmlsZS4gIFRoZSByZXN1bHRpbmcgbG9vcCBkZXZpY2Ugd2lsbCBub3QgaGF2 ZSBkYXggY2FwYWJpbGl0eS4KCiAyLiBTZXQgdXAgdGhlIGRtdGhpbi9kbWxvZ3dyaXRlcyBzdGFj ayBvbiB0b3Agb2YgdGhpcyBsb29wIGRldmljZS4KCiAzLiBDYWxsIG1rZnMueGZzIHdpdGggdGhl IFNDUkFUQ0hfREVWICh3aGljaCBob3BlZnVsbHkgaXMgYSBwbWVtCiAgICBkZXZpY2UpIGFzIHRo ZSByZWFsdGltZSBkZXZpY2UsIGFuZCBzZXQgdGhlIGRheGluaGVyaXQgYW5kIHJ0aW5oZXJpdAog ICAgZmxhZ3Mgb24gdGhlIHJvb3QgZGlyZWN0b3J5LiAgVGhlIHJlc3VsdCBpcyBhIGZpbGVzeXN0 ZW0gd2l0aCBhIGRhdGEKICAgIHNlY3Rpb24gdGhhdCB0aGUga2VybmVsIHdpbGwgdHJlYXQgYXMg YSByZWd1bGFyIGJsb2NrIGRldmljZSwgYQogICAgcmVhbHRpbWUgc2VjdGlvbiBiYWNrZWQgYnkg cG1lbSwgYW5kIHRoZSBuZWNlc3NhcnkgZmxhZ3MgdG8gbWFrZQogICAgc3VyZSB0aGF0IHRoZSB0 ZXN0IGZpbGUgd2lsbCBhY3R1YWxseSBnZXQgZnNkYXggbW9kZS4KCiA0LiBBY2tub3dsZWRnZSB0 aGF0IHdlIG5vIGxvbmdlciBoYXZlIGFueSB3YXkgdG8gdGVzdCBNQVBfU1lOQwogICAgZnVuY3Rp b25hbGl0eSBvbiBleHQ0LCB3aGljaCBtZWFucyB0aGF0IGdlbmVyaWMvNDcwIGhhcyB0byBtb3Zl IHRvCiAgICB0ZXN0cy94ZnMvLgoKLS1ECgo+IFRoYW5rcywKPiAKPiAKPiA+IAo+ID4gLS1ECj4g PiAKPiA+ID4gSWYgbXkgdW5kZXJzdGFuZGluZyBpcyBzb21ldGhpbmcgd3JvbmcsIHBsZWFzZSBj b3JyZWN0IG1lLgo+ID4gPiAKPiA+ID4gKCopaHR0cHM6Ly9sb3JlLmtlcm5lbC5vcmcvYWxsL1RZ V1BSMDFNQjEwMDgyNThGNDc0Q0EyMjk1QjRDRDNEOUI5MDU0OUBUWVdQUjAxTUIxMDA4Mi5qcG5w cmQwMS5wcm9kLm91dGxvb2suY29tLwoKLS0KZG0tZGV2ZWwgbWFpbGluZyBsaXN0CmRtLWRldmVs QHJlZGhhdC5jb20KaHR0cHM6Ly9saXN0bWFuLnJlZGhhdC5jb20vbWFpbG1hbi9saXN0aW5mby9k bS1kZXZlbAo= 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 123C4C433F5 for ; Tue, 4 Oct 2022 18:30:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229870AbiJDS0z (ORCPT ); Tue, 4 Oct 2022 14:26:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56438 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229771AbiJDS0q (ORCPT ); Tue, 4 Oct 2022 14:26:46 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 270415AA0F; Tue, 4 Oct 2022 11:26:45 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 5C879614F8; Tue, 4 Oct 2022 18:26:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B470EC433D6; Tue, 4 Oct 2022 18:26:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1664908003; bh=oOOixuLKdO7T3peG5VpU1afyn8twx99hV9hT8wyH/MQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=tnIrh7v/CUw1AVF/+VFeSsXvTWcmu7o0PZgYDfhzW+23cdLgAD3eOla+HcCdidC/z izXZrfnFJ9azS4hx4bevKP1YGEtyPOfFFiKBM43eBKLt6aBPzUE33VEzWBwXzdSThi ATKPzFmwMqJ4mRn0EbH/x0a7+z6xolAS5LHfBH32OxjYsyhtRC7EauKDloHQwgpOiT YVEnhyWLc6wWTVfgh0KRToWeDVCBypPvM94pNln7eW0IbZGVR23yRDziKA73WU0Zc+ r1MUi2rbbpCpcq2Lhram0ad74G5HlXtu6F3UeMXwYlAMBdp/nmnb9rDkd1/Qca2Lnk mTvW687anHNgQ== Date: Tue, 4 Oct 2022 11:26:43 -0700 From: "Darrick J. Wong" To: =?utf-8?B?R290b3UsIFlhc3Vub3JpL+S6lOWztiDlurfmloc=?= Cc: =?utf-8?B?WWFuZywgWGlhby/mnagg5pmT?= , Brian Foster , "hch@infradead.org" , =?utf-8?B?UnVhbiwgU2hpeWFuZy/pmK4g5LiW6Ziz?= , "linux-kernel@vger.kernel.org" , "linux-xfs@vger.kernel.org" , "nvdimm@lists.linux.dev" , "linux-fsdevel@vger.kernel.org" , "david@fromorbit.com" , zwisler@kernel.org, Jeff Moyer , dm-devel@redhat.com, toshi.kani@hpe.com Subject: Re: [PATCH] xfs: fail dax mount if reflink is enabled on a partition Message-ID: References: <7fdc9e88-f255-6edb-7964-a5a82e9b1292@fujitsu.com> <76ea04b4-bad7-8cb3-d2c6-4ad49def4e05@fujitsu.com> <1444b9b5-363a-163c-0513-55d1ea951799@fujitsu.com> 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-xfs@vger.kernel.org On Mon, Oct 03, 2022 at 09:12:46PM -0700, Gotou, Yasunori/五島 康文 wrote: > On 2022/10/03 17:12, Darrick J. Wong wrote: > > On Fri, Sep 30, 2022 at 09:56:41AM +0900, Gotou, Yasunori/五島 康文 wrote: > > > Hello everyone, > > > > > > On 2022/09/20 11:38, Yang, Xiao/杨 晓 wrote: > > > > Hi Darrick, Brian and Christoph > > > > > > > > Ping. I hope to get your feedback. > > > > > > > > 1) I have confirmed that the following patch set did not change the test > > > > result of generic/470 with thin-volume. Besides, I didn't see any > > > > failure when running generic/470 based on normal PMEM device instaed of > > > > thin-volume. > > > > https://lore.kernel.org/linux-xfs/20211129102203.2243509-1-hch@lst.de/ > > > > > > > > 2) I can reproduce the failure of generic/482 without thin-volume. > > > > > > > > 3) Is it necessary to make thin-volume support DAX. Is there any use > > > > case for the requirement? > > > > > > > > > Though I asked other place(*), I really want to know the usecase of > > > dm-thin-volume with DAX and reflink. > > > > > > > > > In my understanding, dm-thin-volume seems to provide similar feature like > > > reflink of xfs. Both feature provide COW update to reduce usage of > > > its region, and snapshot feature, right? > > > > > > I found that docker seems to select one of them (or other feature which > > > supports COW). Then user don't need to use thin-volume and reflink at same > > > time. > > > > > > Database which uses FS-DAX may want to use snapshot for its data of FS-DAX, > > > its user seems to be satisfied with reflink or thin-volume. > > > > > > So I could not find on what use-case user would like to use dm-thin-volume > > > and reflink at same time. > > > > > > The only possibility is that the user has mistakenly configured dm-thinpool > > > and reflink to be used at the same time, but if that is the case, it seems > > > to be better for the user to disable one or the other. > > > > > > I really wander why dm-thin-volume must be used with reflik and FS-DAX. > > > > There isn't a hard requirement between fsdax and dm-thinp. The /test/ > > needs dm-logwrites to check that write page faults on a MAP_SYNC > > mmapping are persisted directly to disk. dm-logwrites requires a fast > > way to zero an entire device for correct operation of the replay step, > > and thinp is the only way to guarantee that. > > Thank you for your answer. But I still feel something is strange. > Though dm-thinp may be good way to execute the test correctly, Yep. > I suppose it seems to be likely a kind of workaround to pass the test, > it may not be really required for actual users. Exactly correct. Real users should /never/ set up this kind of (test scaffolding|insanity) to use fsdax. > Could you tell me why passing test by workaround is so necessary? Notice this line in generic/470: $XFS_IO_PROG -t -c "truncate $LEN" -c "mmap -S 0 $LEN" -c "mwrite 0 $LEN" \ -c "log_writes -d $LOGWRITES_NAME -m preunmap" \ -f $SCRATCH_MNT/test The second xfs_io command creates a MAP_SYNC mmap of the SCRATCH_MNT/test file, and the third command memcpy's bytes to the mapping to invoke the write page fault handler. The fourth command tells the dm-logwrites driver for $LOGWRITES_NAME (aka the block device containing the mounted XFS filesystem) to create a mark called "preunmap". This mark captures the exact state of the block device immediately after the write faults complete, so that we can come back to it later. There are a few things to note here: (1) We did not tell the fs to persist anything; (2) We can't use dm-snapshot here, because dm-snapshot will flush the fs (I think?); and (3) The fs is still mounted, so the state of the block device at the mark reflects a dirty XFS with a log that must be replayed. The next thing the test does is unmount the fs, remove the dm-logwrites driver to stop recording, and check the fs: _log_writes_unmount _log_writes_remove _dmthin_check_fs This ensures that the post-umount fs is consistent. Now we want to roll back to the place we marked to see if the mwrite data made it to pmem. It *should* have, since we asked for a MAP_SYNC mapping on a fsdax filesystem recorded on a pmem device: # check pre-unmap state _log_writes_replay_log preunmap $DMTHIN_VOL_DEV _dmthin_mount dm-logwrites can't actually roll backwards in time to a mark, since it only records new disk contents. It /can/ however roll forward from whatever point it began recording writes to the mark, so that's what it does. However -- remember note (3) from earlier. When we _dmthin_mount after replaying the log to the "preunmap" mark, XFS will see the dirty XFS log and try to recover the XFS log. This is where the replay problems crop up. The XFS log records a monotonically increasing sequence number (LSN) with every log update, and when updates are written into the filesystem, that LSN is also written into the filesystem block. Log recovery also replays updates into the filesystem, but with the added behavior that it skips a block replay if the block's LSN is higher than the transaction being replayed. IOWs, we never replay older block contents over newer block contents. For dm-logwrites this is a major problem, because there could be more filesystem updates written to the XFS log after the mark is made. LSNs will then be handed out like this: mkfs_lsn preunmap_lsn umount_lsn | | | |--------------------------||----------|-----------| | | xxx_lsn yyy_lsn Let's say that a new metadata block "BBB" was created in update "xxx" immediately before the preunmap mark was made. Per (1), we didn't flush the filesystem before taking the mark, which means that the new block's contents exist only in the log at this point. Let us further say that the new block was again changed in update "yyy", where preunmap_lsn < yyy_lsn <= umount_lsn. Clearly, yyy_lsn > xxx_lsn. yyy_lsn is written to the block at unmount, because unmounting flushes the log clean before it completes. This is the first time that BBB ever gets written. _log_writes_replay_log begins replaying the block device from mkfs_lsn towards preunmap_lsn. When it's done, it will have a log that reflects all the changes up to preunmap_lsn. Recall however that BBB isn't written until after the preunmap mark, which means that dm-logwrites has no record of BBB before preunmap_lsn, so dm-logwrites replay won't touch BBB. At this point, the block header for BBB has a UUID that matches the filesystem, but a LSN (yyy_lsn) that is beyond preunmap_lsn. XFS log recovery starts up, and finds transaction xxx. It will read BBB from disk, but then it will see that it has an LSN of yyy_lsn. This is larger than xxx_lsn, so it concludes that BBB is newer than the log and moves on to the next log item. No other log items touch BBB, so recovery finishes, and now we have a filesystem containing one metadata block (BBB) from the future. This is an inconsistent filesystem, and has caused failures in the tests that use logwrites. To work around this problem, all we really need to do is reinitialize the entire block device to known contents at mkfs time. This can be done expensively by writing zeroes to the entire block device, or it can be done cheaply by (a) issuing DISCARD to the whole the block device at the start of the test and (b) ensuring that reads after a discard always produce zeroes. mkfs.xfs already does (a), so the test merely has to ensure (b). dm-thinp is the only software solution that provides (b), so that's why this test layers dm-logwrites on top of dm-thinp on top of $SCRATCH_DEV. This combination used to work, but with the pending pmem/blockdev divorce, this strategy is no longer feasible. I think the only way to fix this test is (a) revert all of Christoph's changes so far and scuttle the divorce; or (b) change this test like so: 1. Create a large sparse file on $TEST_DIR and losetup that sparse file. The resulting loop device will not have dax capability. 2. Set up the dmthin/dmlogwrites stack on top of this loop device. 3. Call mkfs.xfs with the SCRATCH_DEV (which hopefully is a pmem device) as the realtime device, and set the daxinherit and rtinherit flags on the root directory. The result is a filesystem with a data section that the kernel will treat as a regular block device, a realtime section backed by pmem, and the necessary flags to make sure that the test file will actually get fsdax mode. 4. Acknowledge that we no longer have any way to test MAP_SYNC functionality on ext4, which means that generic/470 has to move to tests/xfs/. --D > Thanks, > > > > > > --D > > > > > If my understanding is something wrong, please correct me. > > > > > > (*)https://lore.kernel.org/all/TYWPR01MB1008258F474CA2295B4CD3D9B90549@TYWPR01MB10082.jpnprd01.prod.outlook.com/