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 64224C8300A for ; Tue, 28 Apr 2020 11:24:50 +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 0D951206D9 for ; Tue, 28 Apr 2020 11:24:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D951206D9 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 D45A0110BD42A; Tue, 28 Apr 2020 04:23:52 -0700 (PDT) Received-SPF: Pass (helo) identity=helo; client-ip=211.29.132.246; helo=mail104.syd.optusnet.com.au; envelope-from=david@fromorbit.com; receiver= Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by ml01.01.org (Postfix) with ESMTP id CB5B21007B7BB for ; Tue, 28 Apr 2020 04:23:49 -0700 (PDT) Received: from dread.disaster.area (pa49-195-157-175.pa.nsw.optusnet.com.au [49.195.157.175]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id C431082144B; Tue, 28 Apr 2020 21:24:42 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1jTOLx-0004Ur-Rg; Tue, 28 Apr 2020 21:24:41 +1000 Date: Tue, 28 Apr 2020 21:24:41 +1000 From: Dave Chinner To: Matthew Wilcox 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: <20200428112441.GH2040@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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20200428111636.GK29705@bombadil.infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=W5xGqiek 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=cxSUJwBmEXFeedIZ3DoA:9 a=QEXdDO2ut3YA:10 a=1CNFftbPRP8L7MoqJWF3:22 a=biEYGPWJfzWAr4FL6Ov7:22 Message-ID-Hash: 3YYA6JQNWJUQPG5XHMUM7WZW7BTMAVP4 X-Message-ID-Hash: 3YYA6JQNWJUQPG5XHMUM7WZW7BTMAVP4 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: "linux-kernel@vger.kernel.org" , "linux-xfs@vger.kernel.org" , "linux-nvdimm@lists.01.org" , "linux-mm@kvack.org" , "linux-fsdevel@vger.kernel.org" , "darrick.wong@oracle.com" , "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 T24gVHVlLCBBcHIgMjgsIDIwMjAgYXQgMDQ6MTY6MzZBTSAtMDcwMCwgTWF0dGhldyBXaWxjb3gg d3JvdGU6DQo+IE9uIFR1ZSwgQXByIDI4LCAyMDIwIGF0IDA1OjMyOjQxUE0gKzA4MDAsIFJ1YW4g U2hpeWFuZyB3cm90ZToNCj4gPiBPbiAyMDIwLzQvMjgg5LiL5Y2IMjo0MywgRGF2ZSBDaGlubmVy IHdyb3RlOg0KPiA+ID4gT24gVHVlLCBBcHIgMjgsIDIwMjAgYXQgMDY6MDk6NDdBTSArMDAwMCwg UnVhbiwgU2hpeWFuZyB3cm90ZToNCj4gPiA+ID4g5ZyoIDIwMjAvNC8yNyAyMDoyODozNiwgIk1h dHRoZXcgV2lsY294IiA8d2lsbHlAaW5mcmFkZWFkLm9yZz4g5YaZ6YGTOg0KPiA+ID4gPiA+IE9u IE1vbiwgQXByIDI3LCAyMDIwIGF0IDA0OjQ3OjQyUE0gKzA4MDAsIFNoaXlhbmcgUnVhbiB3cm90 ZToNCj4gPiA+ID4gPiA+ICAgVGhpcyBwYXRjaHNldCBpcyBhIHRyeSB0byByZXNvbHZlIHRoZSBz aGFyZWQgJ3BhZ2UgY2FjaGUnIHByb2JsZW0gZm9yDQo+ID4gPiA+ID4gPiAgIGZzZGF4Lg0KPiA+ ID4gPiA+ID4gDQo+ID4gPiA+ID4gPiAgIEluIG9yZGVyIHRvIHRyYWNrIG11bHRpcGxlIG1hcHBp bmdzIGFuZCBpbmRleGVzIG9uIG9uZSBwYWdlLCBJDQo+ID4gPiA+ID4gPiAgIGludHJvZHVjZWQg YSBkYXgtcm1hcCByYi10cmVlIHRvIG1hbmFnZSB0aGUgcmVsYXRpb25zaGlwLiAgQSBkYXggZW50 cnkNCj4gPiA+ID4gPiA+ICAgd2lsbCBiZSBhc3NvY2lhdGVkIG1vcmUgdGhhbiBvbmNlIGlmIGlz IHNoYXJlZC4gIEF0IHRoZSBzZWNvbmQgdGltZSB3ZQ0KPiA+ID4gPiA+ID4gICBhc3NvY2lhdGUg dGhpcyBlbnRyeSwgd2UgY3JlYXRlIHRoaXMgcmItdHJlZSBhbmQgc3RvcmUgaXRzIHJvb3QgaW4N Cj4gPiA+ID4gPiA+ICAgcGFnZS0+cHJpdmF0ZShub3QgdXNlZCBpbiBmc2RheCkuICBJbnNlcnQg KC0+bWFwcGluZywgLT5pbmRleCkgd2hlbg0KPiA+ID4gPiA+ID4gICBkYXhfYXNzb2NpYXRlX2Vu dHJ5KCkgYW5kIGRlbGV0ZSBpdCB3aGVuIGRheF9kaXNhc3NvY2lhdGVfZW50cnkoKS4NCj4gPiA+ ID4gPiANCj4gPiA+ID4gPiBEbyB3ZSByZWFsbHkgd2FudCB0byB0cmFjayBhbGwgb2YgdGhpcyBv biBhIHBlci1wYWdlIGJhc2lzPyAgSSB3b3VsZA0KPiA+ID4gPiA+IGhhdmUgdGhvdWdodCBhIHBl ci1leHRlbnQgYmFzaXMgd2FzIG1vcmUgdXNlZnVsLiAgRXNzZW50aWFsbHksIGNyZWF0ZQ0KPiA+ ID4gPiA+IGEgbmV3IGFkZHJlc3Nfc3BhY2UgZm9yIGVhY2ggc2hhcmVkIGV4dGVudC4gIFBlciBw YWdlIGp1c3Qgc2VlbXMgbGlrZQ0KPiA+ID4gPiA+IGEgaHVnZSBvdmVyaGVhZC4NCj4gPiA+ID4g PiANCj4gPiA+ID4gUGVyLWV4dGVudCB0cmFja2luZyBpcyBhIG5pY2UgaWRlYSBmb3IgbWUuICBJ IGhhdmVuJ3QgdGhvdWdodCBvZiBpdA0KPiA+ID4gPiB5ZXQuLi4NCj4gPiA+ID4gDQo+ID4gPiA+ IEJ1dCB0aGUgZXh0ZW50IGluZm8gaXMgbWFpbnRhaW5lZCBieSBmaWxlc3lzdGVtLiAgSSB0aGlu ayB3ZSBuZWVkIGEgd2F5DQo+ID4gPiA+IHRvIG9idGFpbiB0aGlzIGluZm8gZnJvbSBGUyB3aGVu IGFzc29jaWF0aW5nIGEgcGFnZS4gIE1heSBiZSBhIGJpdA0KPiA+ID4gPiBjb21wbGljYXRlZC4g IExldCBtZSB0aGluayBhYm91dCBpdC4uLg0KPiA+ID4gDQo+ID4gPiBUaGF0J3Mgd2h5IEkgd2Fu dCB0aGUgLXVzZXIgb2YgdGhpcyBhc3NvY2lhdGlvbi0gdG8gZG8gYSBmaWxlc3lzdGVtDQo+ID4g PiBjYWxsb3V0IGluc3RlYWQgb2Yga2VlcGluZyBpdCdzIG93biBuYWl2ZSB0cmFja2luZyBpbmZy YXN0cnVjdHVyZS4NCj4gPiA+IFRoZSBmaWxlc3lzdGVtIGNhbiBkbyBhbiBlZmZpY2llbnQsIG9u LWRlbWFuZCByZXZlcnNlIG1hcHBpbmcgbG9va3VwDQo+ID4gPiBmcm9tIGl0J3Mgb3duIGV4dGVu dCB0cmFja2luZyBpbmZyYXN0cnVjdHVyZSwgYW5kIHRoZXJlJ3MgemVybw0KPiA+ID4gcnVudGlt ZSBvdmVyaGVhZCB3aGVuIHRoZXJlIGFyZSBubyBlcnJvcnMgcHJlc2VudC4NCj4gPiA+IA0KPiA+ ID4gQXQgdGhlIG1vbWVudCwgdGhpcyAiZGF4IGFzc29jaWF0aW9uIiBpcyB1c2VkIHRvICJyZXBv cnQiIGEgc3RvcmFnZQ0KPiA+ID4gbWVkaWEgZXJyb3IgZGlyZWN0bHkgdG8gdXNlcnNwYWNlLiBJ IHNheSAicmVwb3J0IiBiZWNhdXNlIHdoYXQgaXQNCj4gPiA+IGRvZXMgaXMga2lsbCB1c2Vyc3Bh Y2UgcHJvY2Vzc2VzIGRlYWQuIFRoZSBzdG9yYWdlIG1lZGlhIGVycm9yDQo+ID4gPiBhY3R1YWxs eSBuZWVkcyB0byBiZSByZXBvcnRlZCB0byB0aGUgb3duZXIgb2YgdGhlIHN0b3JhZ2UgbWVkaWEs DQo+ID4gPiB3aGljaCBpbiB0aGUgY2FzZSBvZiBGUy1EQVggaXMgdGhlIGZpbGVzeXRlbS4NCj4g PiANCj4gPiBVbmRlcnN0b29kLg0KPiA+IA0KPiA+IEJUVywgdGhpcyBpcyB0aGUgdXNhZ2UgaW4g bWVtb3J5LWZhaWx1cmUsIHNvIHdoYXQgYWJvdXQgcm1hcD8gIEkgaGF2ZSBub3QNCj4gPiBmb3Vu ZCBob3cgdG8gdXNlIHRoaXMgdHJhY2tpbmcgaW4gcm1hcC4gIERvIHlvdSBoYXZlIGFueSBpZGVh cz8NCj4gPiANCj4gPiA+IA0KPiA+ID4gVGhhdCB3YXkgdGhlIGZpbGVzeXN0ZW0gY2FuIHRoZW4g bG9vayB1cCBhbGwgdGhlIG93bmVycyBvZiB0aGF0IGJhZA0KPiA+ID4gbWVkaWEgcmFuZ2UgKGku ZS4gdGhlIGZpbGVzeXN0ZW0gYmxvY2sgaXQgY29ycmVzcG9uZHMgdG8pIGFuZCB0YWtlDQo+ID4g PiBhcHByb3ByaWF0ZSBhY3Rpb24uIGUuZy4NCj4gPiANCj4gPiBJIHRyaWVkIHdyaXRpbmcgYSBm dW5jdGlvbiB0byBsb29rIHVwIGFsbCB0aGUgb3duZXJzJyBpbmZvIG9mIG9uZSBibG9jayBpbg0K PiA+IHhmcyBmb3IgbWVtb3J5LWZhaWx1cmUgdXNlLiAgSXQgd2FzIGRyb3BwZWQgaW4gdGhpcyBw YXRjaHNldCBiZWNhdXNlIEkgZm91bmQNCj4gPiBvdXQgdGhhdCB0aGlzIGxvb2t1cCBmdW5jdGlv biBuZWVkcyAncm1hcGJ0JyB0byBiZSBlbmFibGVkIHdoZW4gbWtmcy4gIEJ1dA0KPiA+IGJ5IGRl ZmF1bHQsIHJtYXBidCBpcyBkaXNhYmxlZC4gIEkgYW0gbm90IHN1cmUgaWYgaXQgbWF0dGVycy4u Lg0KPiANCj4gSSdtIHByZXR0eSBzdXJlIHlvdSBjYW4ndCBoYXZlIHNoYXJlZCBleHRlbnRzIG9u IGFuIFhGUyBmaWxlc3lzdGVtIGlmIHlvdQ0KPiBfZG9uJ3RfIGhhdmUgdGhlIHJtYXBidCBmZWF0 dXJlIGVuYWJsZWQuICBJIG1lYW4sIHRoYXQncyB3aHkgaXQgZXhpc3RzLg0KDQpZb3UncmUgY29u ZnVzaW5nIHJlZmxpbmsgd2l0aCBybWFwLiA6KQ0KDQpybWFwYnQgZG9lcyBhbGwgdGhlIHJldmVy c2UgbWFwcGluZyB0cmFja2luZywgcmVmbGluayBqdXN0IGRvZXMgdGhlDQpzaGFyZWQgZGF0YSBl eHRlbnQgdHJhY2tpbmcuDQoNCkJ1dCBnaXZlbiB0aGF0IGFueW9uZSB3aG8gd2FudHMgdG8gdXNl IERBWCB3aXRoIHJlZmxpbmsgaXMgZ29pbmcgdG8NCmhhdmUgdG8gbWtmcyB0aGVpciBmaWxlc3lz dGVtIGFueXdheSAodG8gdHVybiBvbiByZWZsaW5rKSByZXF1aXJpbmcNCnRoYXQgcm1hcGJ0IGlz IGFsc28gdHVybmVkIG9uIGlzIG5vdCBhIGJpZyBkZWFsLiBFc3BlY2lhbGx5IGFzIHdlDQpjYW4g Y2hlY2sgaXQgYXQgbW91bnQgdGltZSBpbiB0aGUga2VybmVsLi4uDQoNCkNoZWVycywNCg0KRGF2 ZS4NCi0tIA0KRGF2ZSBDaGlubmVyDQpkYXZpZEBmcm9tb3JiaXQuY29tCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkxpbnV4LW52ZGltbSBtYWlsaW5nIGxp c3QgLS0gbGludXgtbnZkaW1tQGxpc3RzLjAxLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt YWlsIHRvIGxpbnV4LW52ZGltbS1sZWF2ZUBsaXN0cy4wMS5vcmcK 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 A4D6BC83007 for ; Tue, 28 Apr 2020 11:24:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 8DD93206D6 for ; Tue, 28 Apr 2020 11:24:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726505AbgD1LYt (ORCPT ); Tue, 28 Apr 2020 07:24:49 -0400 Received: from mail104.syd.optusnet.com.au ([211.29.132.246]:45524 "EHLO mail104.syd.optusnet.com.au" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726482AbgD1LYs (ORCPT ); Tue, 28 Apr 2020 07:24:48 -0400 Received: from dread.disaster.area (pa49-195-157-175.pa.nsw.optusnet.com.au [49.195.157.175]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id C431082144B; Tue, 28 Apr 2020 21:24:42 +1000 (AEST) Received: from dave by dread.disaster.area with local (Exim 4.92.3) (envelope-from ) id 1jTOLx-0004Ur-Rg; Tue, 28 Apr 2020 21:24:41 +1000 Date: Tue, 28 Apr 2020 21:24:41 +1000 From: Dave Chinner To: Matthew Wilcox Cc: 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" , "darrick.wong@oracle.com" , "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: <20200428112441.GH2040@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200428111636.GK29705@bombadil.infradead.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.3 cv=W5xGqiek 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=cxSUJwBmEXFeedIZ3DoA:9 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 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... Cheers, Dave. -- Dave Chinner david@fromorbit.com