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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 C5C12C83008 for ; Tue, 28 Apr 2020 22:02:41 +0000 (UTC) Received: from ml01.01.org (ml01.01.org [198.145.21.10]) (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 A51F6206D6 for ; Tue, 28 Apr 2020 22:02:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A51F6206D6 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fromorbit.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nvdimm-bounces@lists.01.org Received: from ml01.vlan13.01.org (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 92F1B110D268C; Tue, 28 Apr 2020 15:01:41 -0700 (PDT) Received-SPF: Pass (helo) identity=helo; client-ip=211.29.132.249; helo=mail105.syd.optusnet.com.au; envelope-from=david@fromorbit.com; receiver= Received: from mail105.syd.optusnet.com.au (mail105.syd.optusnet.com.au [211.29.132.249]) by ml01.01.org (Postfix) with ESMTP id 869121007A9ED for ; Tue, 28 Apr 2020 15:01:38 -0700 (PDT) Received: from dread.disaster.area (pa49-195-157-175.pa.nsw.optusnet.com.au [49.195.157.175]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 3E9873A45A1; Wed, 29 Apr 2020 08:02:33 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1jTYJE-0008Uv-5w; Wed, 29 Apr 2020 08:02:32 +1000 Date: Wed, 29 Apr 2020 08:02:32 +1000 From: Dave Chinner To: "Darrick J. Wong" Subject: Re: =?utf-8?B?5Zue5aSNOiBSZQ==?= =?utf-8?Q?=3A?= [RFC PATCH 0/8] dax: Add a dax-rmap tree to support reflink Message-ID: <20200428220232.GI2040@dread.disaster.area> References: <20200427084750.136031-1-ruansy.fnst@cn.fujitsu.com> <20200427122836.GD29705@bombadil.infradead.org> <20200428064318.GG2040@dread.disaster.area> <259fe633-e1ff-b279-cd8c-1a81eaa40941@cn.fujitsu.com> <20200428111636.GK29705@bombadil.infradead.org> <20200428112441.GH2040@dread.disaster.area> <20200428153732.GZ6742@magnolia> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200428153732.GZ6742@magnolia> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=QIgWuTDL c=1 sm=1 tr=0 a=ONQRW0k9raierNYdzxQi9Q==:117 a=ONQRW0k9raierNYdzxQi9Q==:17 a=IkcTkHD0fZMA:10 a=cl8xLZFz6L8A:10 a=5KLPUuaC_9wA:10 a=JfrnYn6hAAAA:8 a=7-415B0cAAAA:8 a=l6wd5GMc4HtCNSAcdtkA:9 a=z4jTvAT5gXS7p1mQ:21 a=_k9EnfUi_P5Muxk2:21 a=QEXdDO2ut3YA:10 a=1CNFftbPRP8L7MoqJWF3:22 a=biEYGPWJfzWAr4FL6Ov7:22 Message-ID-Hash: KHZWDTOFHTNCIRK6OZET6XEH4PD7VMBL X-Message-ID-Hash: KHZWDTOFHTNCIRK6OZET6XEH4PD7VMBL X-MailFrom: david@fromorbit.com X-Mailman-Rule-Hits: nonmember-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation CC: Matthew Wilcox , "linux-kernel@vger.kernel.org" , "linux-xfs@vger.kernel.org" , "linux-nvdimm@lists.01.org" , "linux-mm@kvack.org" , "linux-fsdevel@vger.kernel.org" , "hch@lst.de" , "rgoldwyn@suse.de" , "Qi, Fuli" , "Gotou, Yasunori" X-Mailman-Version: 3.1.1 Precedence: list List-Id: "Linux-nvdimm developer list." Archived-At: List-Archive: List-Help: List-Post: List-Subscribe: List-Unsubscribe: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gVHVlLCBBcHIgMjgsIDIwMjAgYXQgMDg6Mzc6MzJBTSAtMDcwMCwgRGFycmljayBKLiBXb25n IHdyb3RlOg0KPiBPbiBUdWUsIEFwciAyOCwgMjAyMCBhdCAwOToyNDo0MVBNICsxMDAwLCBEYXZl IENoaW5uZXIgd3JvdGU6DQo+ID4gT24gVHVlLCBBcHIgMjgsIDIwMjAgYXQgMDQ6MTY6MzZBTSAt MDcwMCwgTWF0dGhldyBXaWxjb3ggd3JvdGU6DQo+ID4gPiBPbiBUdWUsIEFwciAyOCwgMjAyMCBh dCAwNTozMjo0MVBNICswODAwLCBSdWFuIFNoaXlhbmcgd3JvdGU6DQo+ID4gPiA+IE9uIDIwMjAv NC8yOCDkuIvljYgyOjQzLCBEYXZlIENoaW5uZXIgd3JvdGU6DQo+ID4gPiA+ID4gT24gVHVlLCBB cHIgMjgsIDIwMjAgYXQgMDY6MDk6NDdBTSArMDAwMCwgUnVhbiwgU2hpeWFuZyB3cm90ZToNCj4g PiA+ID4gPiA+IOWcqCAyMDIwLzQvMjcgMjA6Mjg6MzYsICJNYXR0aGV3IFdpbGNveCIgPHdpbGx5 QGluZnJhZGVhZC5vcmc+IOWGmemBkzoNCj4gPiA+ID4gPiA+ID4gT24gTW9uLCBBcHIgMjcsIDIw MjAgYXQgMDQ6NDc6NDJQTSArMDgwMCwgU2hpeWFuZyBSdWFuIHdyb3RlOg0KPiA+ID4gPiA+ID4g PiA+ICAgVGhpcyBwYXRjaHNldCBpcyBhIHRyeSB0byByZXNvbHZlIHRoZSBzaGFyZWQgJ3BhZ2Ug Y2FjaGUnIHByb2JsZW0gZm9yDQo+ID4gPiA+ID4gPiA+ID4gICBmc2RheC4NCj4gPiA+ID4gPiA+ ID4gPiANCj4gPiA+ID4gPiA+ID4gPiAgIEluIG9yZGVyIHRvIHRyYWNrIG11bHRpcGxlIG1hcHBp bmdzIGFuZCBpbmRleGVzIG9uIG9uZSBwYWdlLCBJDQo+ID4gPiA+ID4gPiA+ID4gICBpbnRyb2R1 Y2VkIGEgZGF4LXJtYXAgcmItdHJlZSB0byBtYW5hZ2UgdGhlIHJlbGF0aW9uc2hpcC4gIEEgZGF4 IGVudHJ5DQo+ID4gPiA+ID4gPiA+ID4gICB3aWxsIGJlIGFzc29jaWF0ZWQgbW9yZSB0aGFuIG9u Y2UgaWYgaXMgc2hhcmVkLiAgQXQgdGhlIHNlY29uZCB0aW1lIHdlDQo+ID4gPiA+ID4gPiA+ID4g ICBhc3NvY2lhdGUgdGhpcyBlbnRyeSwgd2UgY3JlYXRlIHRoaXMgcmItdHJlZSBhbmQgc3RvcmUg aXRzIHJvb3QgaW4NCj4gPiA+ID4gPiA+ID4gPiAgIHBhZ2UtPnByaXZhdGUobm90IHVzZWQgaW4g ZnNkYXgpLiAgSW5zZXJ0ICgtPm1hcHBpbmcsIC0+aW5kZXgpIHdoZW4NCj4gPiA+ID4gPiA+ID4g PiAgIGRheF9hc3NvY2lhdGVfZW50cnkoKSBhbmQgZGVsZXRlIGl0IHdoZW4gZGF4X2Rpc2Fzc29j aWF0ZV9lbnRyeSgpLg0KPiA+ID4gPiA+ID4gPiANCj4gPiA+ID4gPiA+ID4gRG8gd2UgcmVhbGx5 IHdhbnQgdG8gdHJhY2sgYWxsIG9mIHRoaXMgb24gYSBwZXItcGFnZSBiYXNpcz8gIEkgd291bGQN Cj4gPiA+ID4gPiA+ID4gaGF2ZSB0aG91Z2h0IGEgcGVyLWV4dGVudCBiYXNpcyB3YXMgbW9yZSB1 c2VmdWwuICBFc3NlbnRpYWxseSwgY3JlYXRlDQo+ID4gPiA+ID4gPiA+IGEgbmV3IGFkZHJlc3Nf c3BhY2UgZm9yIGVhY2ggc2hhcmVkIGV4dGVudC4gIFBlciBwYWdlIGp1c3Qgc2VlbXMgbGlrZQ0K PiA+ID4gPiA+ID4gPiBhIGh1Z2Ugb3ZlcmhlYWQuDQo+ID4gPiA+ID4gPiA+IA0KPiA+ID4gPiA+ ID4gUGVyLWV4dGVudCB0cmFja2luZyBpcyBhIG5pY2UgaWRlYSBmb3IgbWUuICBJIGhhdmVuJ3Qg dGhvdWdodCBvZiBpdA0KPiA+ID4gPiA+ID4geWV0Li4uDQo+ID4gPiA+ID4gPiANCj4gPiA+ID4g PiA+IEJ1dCB0aGUgZXh0ZW50IGluZm8gaXMgbWFpbnRhaW5lZCBieSBmaWxlc3lzdGVtLiAgSSB0 aGluayB3ZSBuZWVkIGEgd2F5DQo+ID4gPiA+ID4gPiB0byBvYnRhaW4gdGhpcyBpbmZvIGZyb20g RlMgd2hlbiBhc3NvY2lhdGluZyBhIHBhZ2UuICBNYXkgYmUgYSBiaXQNCj4gPiA+ID4gPiA+IGNv bXBsaWNhdGVkLiAgTGV0IG1lIHRoaW5rIGFib3V0IGl0Li4uDQo+ID4gPiA+ID4gDQo+ID4gPiA+ ID4gVGhhdCdzIHdoeSBJIHdhbnQgdGhlIC11c2VyIG9mIHRoaXMgYXNzb2NpYXRpb24tIHRvIGRv IGEgZmlsZXN5c3RlbQ0KPiA+ID4gPiA+IGNhbGxvdXQgaW5zdGVhZCBvZiBrZWVwaW5nIGl0J3Mg b3duIG5haXZlIHRyYWNraW5nIGluZnJhc3RydWN0dXJlLg0KPiA+ID4gPiA+IFRoZSBmaWxlc3lz dGVtIGNhbiBkbyBhbiBlZmZpY2llbnQsIG9uLWRlbWFuZCByZXZlcnNlIG1hcHBpbmcgbG9va3Vw DQo+ID4gPiA+ID4gZnJvbSBpdCdzIG93biBleHRlbnQgdHJhY2tpbmcgaW5mcmFzdHJ1Y3R1cmUs IGFuZCB0aGVyZSdzIHplcm8NCj4gPiA+ID4gPiBydW50aW1lIG92ZXJoZWFkIHdoZW4gdGhlcmUg YXJlIG5vIGVycm9ycyBwcmVzZW50Lg0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+IEF0IHRoZSBtb21l bnQsIHRoaXMgImRheCBhc3NvY2lhdGlvbiIgaXMgdXNlZCB0byAicmVwb3J0IiBhIHN0b3JhZ2UN Cj4gPiA+ID4gPiBtZWRpYSBlcnJvciBkaXJlY3RseSB0byB1c2Vyc3BhY2UuIEkgc2F5ICJyZXBv cnQiIGJlY2F1c2Ugd2hhdCBpdA0KPiA+ID4gPiA+IGRvZXMgaXMga2lsbCB1c2Vyc3BhY2UgcHJv Y2Vzc2VzIGRlYWQuIFRoZSBzdG9yYWdlIG1lZGlhIGVycm9yDQo+ID4gPiA+ID4gYWN0dWFsbHkg bmVlZHMgdG8gYmUgcmVwb3J0ZWQgdG8gdGhlIG93bmVyIG9mIHRoZSBzdG9yYWdlIG1lZGlhLA0K PiA+ID4gPiA+IHdoaWNoIGluIHRoZSBjYXNlIG9mIEZTLURBWCBpcyB0aGUgZmlsZXN5dGVtLg0K PiA+ID4gPiANCj4gPiA+ID4gVW5kZXJzdG9vZC4NCj4gPiA+ID4gDQo+ID4gPiA+IEJUVywgdGhp cyBpcyB0aGUgdXNhZ2UgaW4gbWVtb3J5LWZhaWx1cmUsIHNvIHdoYXQgYWJvdXQgcm1hcD8gIEkg aGF2ZSBub3QNCj4gPiA+ID4gZm91bmQgaG93IHRvIHVzZSB0aGlzIHRyYWNraW5nIGluIHJtYXAu ICBEbyB5b3UgaGF2ZSBhbnkgaWRlYXM/DQo+ID4gPiA+IA0KPiA+ID4gPiA+IA0KPiA+ID4gPiA+ IFRoYXQgd2F5IHRoZSBmaWxlc3lzdGVtIGNhbiB0aGVuIGxvb2sgdXAgYWxsIHRoZSBvd25lcnMg b2YgdGhhdCBiYWQNCj4gPiA+ID4gPiBtZWRpYSByYW5nZSAoaS5lLiB0aGUgZmlsZXN5c3RlbSBi bG9jayBpdCBjb3JyZXNwb25kcyB0bykgYW5kIHRha2UNCj4gPiA+ID4gPiBhcHByb3ByaWF0ZSBh Y3Rpb24uIGUuZy4NCj4gPiA+ID4gDQo+ID4gPiA+IEkgdHJpZWQgd3JpdGluZyBhIGZ1bmN0aW9u IHRvIGxvb2sgdXAgYWxsIHRoZSBvd25lcnMnIGluZm8gb2Ygb25lIGJsb2NrIGluDQo+ID4gPiA+ IHhmcyBmb3IgbWVtb3J5LWZhaWx1cmUgdXNlLiAgSXQgd2FzIGRyb3BwZWQgaW4gdGhpcyBwYXRj aHNldCBiZWNhdXNlIEkgZm91bmQNCj4gPiA+ID4gb3V0IHRoYXQgdGhpcyBsb29rdXAgZnVuY3Rp b24gbmVlZHMgJ3JtYXBidCcgdG8gYmUgZW5hYmxlZCB3aGVuIG1rZnMuICBCdXQNCj4gPiA+ID4g YnkgZGVmYXVsdCwgcm1hcGJ0IGlzIGRpc2FibGVkLiAgSSBhbSBub3Qgc3VyZSBpZiBpdCBtYXR0 ZXJzLi4uDQo+ID4gPiANCj4gPiA+IEknbSBwcmV0dHkgc3VyZSB5b3UgY2FuJ3QgaGF2ZSBzaGFy ZWQgZXh0ZW50cyBvbiBhbiBYRlMgZmlsZXN5c3RlbSBpZiB5b3UNCj4gPiA+IF9kb24ndF8gaGF2 ZSB0aGUgcm1hcGJ0IGZlYXR1cmUgZW5hYmxlZC4gIEkgbWVhbiwgdGhhdCdzIHdoeSBpdCBleGlz dHMuDQo+ID4gDQo+ID4gWW91J3JlIGNvbmZ1c2luZyByZWZsaW5rIHdpdGggcm1hcC4gOikNCj4g PiANCj4gPiBybWFwYnQgZG9lcyBhbGwgdGhlIHJldmVyc2UgbWFwcGluZyB0cmFja2luZywgcmVm bGluayBqdXN0IGRvZXMgdGhlDQo+ID4gc2hhcmVkIGRhdGEgZXh0ZW50IHRyYWNraW5nLg0KPiA+ IA0KPiA+IEJ1dCBnaXZlbiB0aGF0IGFueW9uZSB3aG8gd2FudHMgdG8gdXNlIERBWCB3aXRoIHJl ZmxpbmsgaXMgZ29pbmcgdG8NCj4gPiBoYXZlIHRvIG1rZnMgdGhlaXIgZmlsZXN5c3RlbSBhbnl3 YXkgKHRvIHR1cm4gb24gcmVmbGluaykgcmVxdWlyaW5nDQo+ID4gdGhhdCBybWFwYnQgaXMgYWxz byB0dXJuZWQgb24gaXMgbm90IGEgYmlnIGRlYWwuIEVzcGVjaWFsbHkgYXMgd2UNCj4gPiBjYW4g Y2hlY2sgaXQgYXQgbW91bnQgdGltZSBpbiB0aGUga2VybmVsLi4uDQo+IA0KPiBBcmUgd2UgZ29p bmcgdG8gdHVybiBvbiBybWFwIGJ5IGRlZmF1bHQ/ICBUaGUgbGFzdCBJIGNoZWNrZWQsIGl0IGRp ZA0KPiBoYXZlIGEgMTAtMjAlIHBlcmZvcm1hbmNlIGNvc3Qgb24gZXh0cmVtZSBtZXRhZGF0YS1o ZWF2eSB3b3JrbG9hZHMuDQo+IE9yIGRvIHdlIG9ubHkgZW5hYmxlIGl0IGJ5IGRlZmF1bHQgaWYg bWtmcyBkZXRlY3RzIGEgcG1lbSBkZXZpY2U/DQoNCkp1c3QgaGF2ZSB0aGUga2VybmVsIHJlZnVz ZSB0byBtb3VudCBhIHJlZmxpbmsgZW5hYmxlZCBmaWxlc3lzdGVtIG9uDQphIERBWCBjYXBhYmxl IGRldmljZSB1bmxlc3MgLW8gZGF4PW5ldmVyIG9yIHJtYXBidCBpcyBlbmFibGVkLg0KDQpUaGF0 J2xsIGdldCB0aGUgbWVzc2FnZSBhY3Jvc3MgcHJldHR5IHF1aWNrbHkuLi4uDQoNCj4gKEFkbWl0 dGVkbHksIG1vc3QgcGVvcGxlIGRvIG5vdCBydW4gZnN4IGFzIGEgcHJvZHVjdGl2aXR5IGFwcDsg dGhlDQo+IG5vcm1hbCBoaXQgaXMgdXN1YWxseSAzLTUlIHdoaWNoIG1pZ2h0IG5vdCBiZSBzdWNo IGEgYmlnIGRlYWwgc2luY2UgeW91DQo+IGFsc28gZ2V0IChoYWxmIG9mKSBvbmxpbmUgZnNjay4g OlApDQoNCkkgaGF2ZSBub3Qgbm90aWNlZCB0aGUgb3ZlcmhlYWQgYXQgYWxsIG9uIGFueSBvZiBt eSBwcm9kdWN0aW9uDQptYWNoaW5lcyBzaW5jZSBJIGVuYWJsZWQgaXQgd2F5IG9uIGFsbCBvZiB0 aGVtIHdheSBiYWNrIHdoZW4uLi4uDQoNCkFuZCwgcmVhbGx5LCBwbWVtIGlzIGEgX3ZlcnkgcG9v ciBjaG9pY2VfIGZvciBtZXRhZGF0YSBpbnRlbnNpdmUNCmFwcGxpY2F0aW9ucyBvbiBYRlMgYXMg cG1lbSBpcyBjb21wbGV0ZWx5IHN5bmNocm9ub3VzLiAgWEZTIGhhcyBhbg0KYXN5bmMgSU8gbW9k ZWwgZm9yIGl0J3MgbWV0YWRhdGEgdGhhdCAqbXVzdCogYmUgYnVmZmVyZWQgKHNvIG5vDQpEQVgh KSBhbmQgdGhlIHN5bmNocm9ub3VzIG5hdHVyZSBvZiBwbWVtIGNvbXBsZXRlbHkgZGVmZWF0cyB0 aGUNCmFyY2hpdGVjdHVyYWwgSU8gcGlwZWxpbmluZyBYRlMgdXNlcyB0byBhbGxvdyB0aG91c2Fu ZHMgb2YNCmNvbmN1cnJlbnQgbWV0YWRhdGEgSU9zIGluIGZsaWdodC4gT1RPSCwgcG1lbSBJTyBk ZXB0aCBpcyBsaW1pdGVkIHRvDQp0aGUgbnVtYmVyIG9mIENQVXMgdGhhdCBhcmUgY29uY3VycmVu dGx5IGlzc3VpbmcgSU8sIHNvIGl0IHJlYWxseSwNCnJlYWxseSBzdWNrcyBjb21wYXJlZCB0byBh IGhhbmRmdWwgb2YgaGlnaCBlbmQgbnZtZSBTU0RzIG9uIFBDSWUNCjQuMC4uLi4NCg0KU28gd2l0 aCB0aGF0IGluIG1pbmQsIEkgc2VlIGxpdHRsZSByZWFzb24gdG8gY2FyZSBhYm91dCB0aGUgc21h bGwNCmFkZGl0aW9uYWwgb3ZlcmhlYWQgb2Ygcm1hcGJ0IG9uIEZTLURBWCBpbnN0YWxsYXRpb25z IHRoYXQgcmVxdWlyZQ0KcmVmbGluay4uLg0KDQpDaGVlcnMsDQoNCkRhdmUuDQotLSANCkRhdmUg Q2hpbm5lcg0KZGF2aWRAZnJvbW9yYml0LmNvbQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXwpMaW51eC1udmRpbW0gbWFpbGluZyBsaXN0IC0tIGxpbnV4LW52 ZGltbUBsaXN0cy4wMS5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byBsaW51eC1u dmRpbW0tbGVhdmVAbGlzdHMuMDEub3JnCg== 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=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,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 47D98C83007 for ; Tue, 28 Apr 2020 22:02:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 2D45E2072A for ; Tue, 28 Apr 2020 22:02:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726279AbgD1WCl (ORCPT ); Tue, 28 Apr 2020 18:02:41 -0400 Received: from mail105.syd.optusnet.com.au ([211.29.132.249]:41588 "EHLO mail105.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726343AbgD1WCl (ORCPT ); Tue, 28 Apr 2020 18:02:41 -0400 Received: from dread.disaster.area (pa49-195-157-175.pa.nsw.optusnet.com.au [49.195.157.175]) by mail105.syd.optusnet.com.au (Postfix) with ESMTPS id 3E9873A45A1; Wed, 29 Apr 2020 08:02:33 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1jTYJE-0008Uv-5w; Wed, 29 Apr 2020 08:02:32 +1000 Date: Wed, 29 Apr 2020 08:02:32 +1000 From: Dave Chinner To: "Darrick J. Wong" Cc: Matthew Wilcox , Ruan Shiyang , "linux-kernel@vger.kernel.org" , "linux-xfs@vger.kernel.org" , "linux-nvdimm@lists.01.org" , "linux-mm@kvack.org" , "linux-fsdevel@vger.kernel.org" , "dan.j.williams@intel.com" , "hch@lst.de" , "rgoldwyn@suse.de" , "Qi, Fuli" , "Gotou, Yasunori" Subject: Re: =?utf-8?B?5Zue5aSNOiBSZQ==?= =?utf-8?Q?=3A?= [RFC PATCH 0/8] dax: Add a dax-rmap tree to support reflink Message-ID: <20200428220232.GI2040@dread.disaster.area> References: <20200427084750.136031-1-ruansy.fnst@cn.fujitsu.com> <20200427122836.GD29705@bombadil.infradead.org> <20200428064318.GG2040@dread.disaster.area> <259fe633-e1ff-b279-cd8c-1a81eaa40941@cn.fujitsu.com> <20200428111636.GK29705@bombadil.infradead.org> <20200428112441.GH2040@dread.disaster.area> <20200428153732.GZ6742@magnolia> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200428153732.GZ6742@magnolia> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=QIgWuTDL c=1 sm=1 tr=0 a=ONQRW0k9raierNYdzxQi9Q==:117 a=ONQRW0k9raierNYdzxQi9Q==:17 a=IkcTkHD0fZMA:10 a=cl8xLZFz6L8A:10 a=5KLPUuaC_9wA:10 a=JfrnYn6hAAAA:8 a=7-415B0cAAAA:8 a=l6wd5GMc4HtCNSAcdtkA:9 a=z4jTvAT5gXS7p1mQ:21 a=_k9EnfUi_P5Muxk2:21 a=QEXdDO2ut3YA:10 a=1CNFftbPRP8L7MoqJWF3:22 a=biEYGPWJfzWAr4FL6Ov7:22 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Tue, Apr 28, 2020 at 08:37:32AM -0700, Darrick J. Wong wrote: > On Tue, Apr 28, 2020 at 09:24:41PM +1000, Dave Chinner wrote: > > On Tue, Apr 28, 2020 at 04:16:36AM -0700, Matthew Wilcox wrote: > > > On Tue, Apr 28, 2020 at 05:32:41PM +0800, Ruan Shiyang wrote: > > > > On 2020/4/28 下午2:43, Dave Chinner wrote: > > > > > On Tue, Apr 28, 2020 at 06:09:47AM +0000, Ruan, Shiyang wrote: > > > > > > 在 2020/4/27 20:28:36, "Matthew Wilcox" 写道: > > > > > > > On Mon, Apr 27, 2020 at 04:47:42PM +0800, Shiyang Ruan wrote: > > > > > > > > This patchset is a try to resolve the shared 'page cache' problem for > > > > > > > > fsdax. > > > > > > > > > > > > > > > > In order to track multiple mappings and indexes on one page, I > > > > > > > > introduced a dax-rmap rb-tree to manage the relationship. A dax entry > > > > > > > > will be associated more than once if is shared. At the second time we > > > > > > > > associate this entry, we create this rb-tree and store its root in > > > > > > > > page->private(not used in fsdax). Insert (->mapping, ->index) when > > > > > > > > dax_associate_entry() and delete it when dax_disassociate_entry(). > > > > > > > > > > > > > > Do we really want to track all of this on a per-page basis? I would > > > > > > > have thought a per-extent basis was more useful. Essentially, create > > > > > > > a new address_space for each shared extent. Per page just seems like > > > > > > > a huge overhead. > > > > > > > > > > > > > Per-extent tracking is a nice idea for me. I haven't thought of it > > > > > > yet... > > > > > > > > > > > > But the extent info is maintained by filesystem. I think we need a way > > > > > > to obtain this info from FS when associating a page. May be a bit > > > > > > complicated. Let me think about it... > > > > > > > > > > That's why I want the -user of this association- to do a filesystem > > > > > callout instead of keeping it's own naive tracking infrastructure. > > > > > The filesystem can do an efficient, on-demand reverse mapping lookup > > > > > from it's own extent tracking infrastructure, and there's zero > > > > > runtime overhead when there are no errors present. > > > > > > > > > > At the moment, this "dax association" is used to "report" a storage > > > > > media error directly to userspace. I say "report" because what it > > > > > does is kill userspace processes dead. The storage media error > > > > > actually needs to be reported to the owner of the storage media, > > > > > which in the case of FS-DAX is the filesytem. > > > > > > > > Understood. > > > > > > > > BTW, this is the usage in memory-failure, so what about rmap? I have not > > > > found how to use this tracking in rmap. Do you have any ideas? > > > > > > > > > > > > > > That way the filesystem can then look up all the owners of that bad > > > > > media range (i.e. the filesystem block it corresponds to) and take > > > > > appropriate action. e.g. > > > > > > > > I tried writing a function to look up all the owners' info of one block in > > > > xfs for memory-failure use. It was dropped in this patchset because I found > > > > out that this lookup function needs 'rmapbt' to be enabled when mkfs. But > > > > by default, rmapbt is disabled. I am not sure if it matters... > > > > > > I'm pretty sure you can't have shared extents on an XFS filesystem if you > > > _don't_ have the rmapbt feature enabled. I mean, that's why it exists. > > > > You're confusing reflink with rmap. :) > > > > rmapbt does all the reverse mapping tracking, reflink just does the > > shared data extent tracking. > > > > But given that anyone who wants to use DAX with reflink is going to > > have to mkfs their filesystem anyway (to turn on reflink) requiring > > that rmapbt is also turned on is not a big deal. Especially as we > > can check it at mount time in the kernel... > > Are we going to turn on rmap by default? The last I checked, it did > have a 10-20% performance cost on extreme metadata-heavy workloads. > Or do we only enable it by default if mkfs detects a pmem device? Just have the kernel refuse to mount a reflink enabled filesystem on a DAX capable device unless -o dax=never or rmapbt is enabled. That'll get the message across pretty quickly.... > (Admittedly, most people do not run fsx as a productivity app; the > normal hit is usually 3-5% which might not be such a big deal since you > also get (half of) online fsck. :P) I have not noticed the overhead at all on any of my production machines since I enabled it way on all of them way back when.... And, really, pmem is a _very poor choice_ for metadata intensive applications on XFS as pmem is completely synchronous. XFS has an async IO model for it's metadata that *must* be buffered (so no DAX!) and the synchronous nature of pmem completely defeats the architectural IO pipelining XFS uses to allow thousands of concurrent metadata IOs in flight. OTOH, pmem IO depth is limited to the number of CPUs that are concurrently issuing IO, so it really, really sucks compared to a handful of high end nvme SSDs on PCIe 4.0.... So with that in mind, I see little reason to care about the small additional overhead of rmapbt on FS-DAX installations that require reflink... Cheers, Dave. -- Dave Chinner david@fromorbit.com