From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Kani, Toshi" Subject: Re: [PATCH v2 5/7] dm: remove DM_TYPE_DAX_BIO_BASED dm_queue_mode Date: Mon, 4 Jun 2018 23:49:18 +0000 Message-ID: <1528156065.14039.113.camel@hpe.com> References: <20180529195106.14268-1-ross.zwisler@linux.intel.com> <20180529195106.14268-6-ross.zwisler@linux.intel.com> <20180601220443.GB18712@redhat.com> <20180604232416.GB10666@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20180604232416.GB10666-VuQAYsv1563Yd54FQh9/CA@public.gmane.org> Content-Language: en-US Content-ID: <1D4ACA0B174EA340BD68FDA59FFD6084-mmYPd6ayCNGroOM5E8FhRbjFIynDaujOfM0AETQt39g@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-nvdimm-bounces-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org Sender: "Linux-nvdimm" To: "ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org" , "snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" Cc: "linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org" , "linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , "linux-xfs-u79uwXL29TYaXLmJjATzhQ@public.gmane.org" , "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" List-Id: dm-devel.ids On Mon, 2018-06-04 at 17:24 -0600, Ross Zwisler wrote: > On Fri, Jun 01, 2018 at 06:04:43PM -0400, Mike Snitzer wrote: > > On Tue, May 29 2018 at 3:51pm -0400, > > Ross Zwisler wrote: : > > For example, the following transition will currently fail: > > > > dm-linear: [fsdax pmem][fsdax pmem] => [fsdax pmem][fsdax raw] > > DM_TYPE_DAX_BIO_BASED DM_TYPE_BIO_BASED > > > > but these will both succeed: > > > > dm-linear: [fsdax pmem][brd ramdisk] => [fsdax pmem][fsdax raw] > > DM_TYPE_BIO_BASED DM_TYPE_BIO_BASED > > > > dm-linear: [fsdax pmem][fsdax raw] => [fsdax pmem][fsdax pmem] > > DM_TYPE_BIO_BASED DM_TYPE_DAX_BIO_BASED > > So we allow 2 of the 3 transitions, but the reason that we disallow the third > isn't fully clear to me. I need to refresh my memory for the code, but here is the intent. https://lkml.org/lkml/2016/6/22/1000 https://lkml.org/lkml/2016/6/22/999 > > > dm-linear: [fsdax pmem][fsdax raw] => [fsdax pmem][fsdax pmem] > > > DM_TYPE_BIO_BASED DM_TYPE_DAX_BIO_BASED > > > > > > This seems arbitrary, as really the choice on whether to use DAX happens at > > > filesystem mount time. There's no guarantee that the in the first case > > > (double fsdax pmem) we were using the dax mount option with our file > > > system. > > > > > > Instead, get rid of DM_TYPE_DAX_BIO_BASED and all the special casing around > > > it, and instead make the request queue's QUEUE_FLAG_DAX be our one source > > > of truth. If this is set, we can use DAX, and if not, not. We keep this > > > up to date in table_load() as the table changes. As with regular block > > > devices the filesystem will then know at mount time whether DAX is a > > > supported mount option or not. > > > > If you don't think you need this specialization that is fine.. but DM > > devices supporting suspending (as part of table reloads) so is there any > > risk that there will be inflight IO (say if someone did 'dmsetup suspend > > --noflush').. and then upon reload the device type changed out from > > under us.. anyway, I don't have all the PMEM DAX stuff paged back into > > my head yet. > > > > But this just seems like we really shouldn't be allowing the > > transition from what was DM_TYPE_DAX_BIO_BASED back to DM_TYPE_BIO_BASED > > I admit I don't fully understand all the ways that DM supports suspending and > resuming devices. Is there actually a case where we can change out the DM > devices while I/O is running, and somehow end up trying to issue a DAX I/O to > a device that doesn't support DAX? > > Toshi, do you have a test case that shows this somehow? No, I did not test suspend/resume since HPE servers do not support it. Thanks, -Toshi From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g4t3425.houston.hpe.com (g4t3425.houston.hpe.com [15.241.140.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id D63BB209605D2 for ; Mon, 4 Jun 2018 16:49:21 -0700 (PDT) From: "Kani, Toshi" Subject: Re: [PATCH v2 5/7] dm: remove DM_TYPE_DAX_BIO_BASED dm_queue_mode Date: Mon, 4 Jun 2018 23:49:18 +0000 Message-ID: <1528156065.14039.113.camel@hpe.com> References: <20180529195106.14268-1-ross.zwisler@linux.intel.com> <20180529195106.14268-6-ross.zwisler@linux.intel.com> <20180601220443.GB18712@redhat.com> <20180604232416.GB10666@linux.intel.com> In-Reply-To: <20180604232416.GB10666@linux.intel.com> Content-Language: en-US Content-ID: <1D4ACA0B174EA340BD68FDA59FFD6084@NAMPRD84.PROD.OUTLOOK.COM> MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: "ross.zwisler@linux.intel.com" , "snitzer@redhat.com" Cc: "linux-fsdevel@vger.kernel.org" , "dm-devel@redhat.com" , "linux-kernel@vger.kernel.org" , "linux-xfs@vger.kernel.orgw" , "linux-nvdimm@lists.01.org" List-ID: On Mon, 2018-06-04 at 17:24 -0600, Ross Zwisler wrote: > On Fri, Jun 01, 2018 at 06:04:43PM -0400, Mike Snitzer wrote: > > On Tue, May 29 2018 at 3:51pm -0400, > > Ross Zwisler wrote: : > > For example, the following transition will currently fail: > > > > dm-linear: [fsdax pmem][fsdax pmem] => [fsdax pmem][fsdax raw] > > DM_TYPE_DAX_BIO_BASED DM_TYPE_BIO_BASED > > > > but these will both succeed: > > > > dm-linear: [fsdax pmem][brd ramdisk] => [fsdax pmem][fsdax raw] > > DM_TYPE_BIO_BASED DM_TYPE_BIO_BASED > > > > dm-linear: [fsdax pmem][fsdax raw] => [fsdax pmem][fsdax pmem] > > DM_TYPE_BIO_BASED DM_TYPE_DAX_BIO_BASED > > So we allow 2 of the 3 transitions, but the reason that we disallow the third > isn't fully clear to me. I need to refresh my memory for the code, but here is the intent. https://lkml.org/lkml/2016/6/22/1000 https://lkml.org/lkml/2016/6/22/999 > > > dm-linear: [fsdax pmem][fsdax raw] => [fsdax pmem][fsdax pmem] > > > DM_TYPE_BIO_BASED DM_TYPE_DAX_BIO_BASED > > > > > > This seems arbitrary, as really the choice on whether to use DAX happens at > > > filesystem mount time. There's no guarantee that the in the first case > > > (double fsdax pmem) we were using the dax mount option with our file > > > system. > > > > > > Instead, get rid of DM_TYPE_DAX_BIO_BASED and all the special casing around > > > it, and instead make the request queue's QUEUE_FLAG_DAX be our one source > > > of truth. If this is set, we can use DAX, and if not, not. We keep this > > > up to date in table_load() as the table changes. As with regular block > > > devices the filesystem will then know at mount time whether DAX is a > > > supported mount option or not. > > > > If you don't think you need this specialization that is fine.. but DM > > devices supporting suspending (as part of table reloads) so is there any > > risk that there will be inflight IO (say if someone did 'dmsetup suspend > > --noflush').. and then upon reload the device type changed out from > > under us.. anyway, I don't have all the PMEM DAX stuff paged back into > > my head yet. > > > > But this just seems like we really shouldn't be allowing the > > transition from what was DM_TYPE_DAX_BIO_BASED back to DM_TYPE_BIO_BASED > > I admit I don't fully understand all the ways that DM supports suspending and > resuming devices. Is there actually a case where we can change out the DM > devices while I/O is running, and somehow end up trying to issue a DAX I/O to > a device that doesn't support DAX? > > Toshi, do you have a test case that shows this somehow? No, I did not test suspend/resume since HPE servers do not support it. Thanks, -Toshi _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g9t1613g.houston.hpe.com ([15.241.32.99]:30918 "EHLO g9t1613g.houston.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752003AbeFDXtW (ORCPT ); Mon, 4 Jun 2018 19:49:22 -0400 Received: from g4t3425.houston.hpe.com (g4t3425.houston.hpe.com [15.241.140.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by g9t1613g.houston.hpe.com (Postfix) with ESMTPS id D884C60DED for ; Mon, 4 Jun 2018 23:49:21 +0000 (UTC) From: "Kani, Toshi" To: "ross.zwisler@linux.intel.com" , "snitzer@redhat.com" CC: "dm-devel@redhat.com" , "linux-kernel@vger.kernel.org" , "linux-nvdimm@lists.01.org" , "linux-xfs@vger.kernel.orgw" , "linux-fsdevel@vger.kernel.org" Subject: Re: [PATCH v2 5/7] dm: remove DM_TYPE_DAX_BIO_BASED dm_queue_mode Date: Mon, 4 Jun 2018 23:49:18 +0000 Message-ID: <1528156065.14039.113.camel@hpe.com> References: <20180529195106.14268-1-ross.zwisler@linux.intel.com> <20180529195106.14268-6-ross.zwisler@linux.intel.com> <20180601220443.GB18712@redhat.com> <20180604232416.GB10666@linux.intel.com> In-Reply-To: <20180604232416.GB10666@linux.intel.com> Content-Language: en-US Content-Type: text/plain; charset="utf-8" Content-ID: <1D4ACA0B174EA340BD68FDA59FFD6084@NAMPRD84.PROD.OUTLOOK.COM> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: T24gTW9uLCAyMDE4LTA2LTA0IGF0IDE3OjI0IC0wNjAwLCBSb3NzIFp3aXNsZXIgd3JvdGU6DQo+ IE9uIEZyaSwgSnVuIDAxLCAyMDE4IGF0IDA2OjA0OjQzUE0gLTA0MDAsIE1pa2UgU25pdHplciB3 cm90ZToNCj4gPiBPbiBUdWUsIE1heSAyOSAyMDE4IGF0ICAzOjUxcG0gLTA0MDAsDQo+ID4gUm9z cyBad2lzbGVyIDxyb3NzLnp3aXNsZXJAbGludXguaW50ZWwuY29tPiB3cm90ZToNCiA6DQo+ID4g Rm9yIGV4YW1wbGUsIHRoZSBmb2xsb3dpbmcgdHJhbnNpdGlvbiB3aWxsIGN1cnJlbnRseSBmYWls Og0KPiA+IA0KPiA+ICBkbS1saW5lYXI6IFtmc2RheCBwbWVtXVtmc2RheCBwbWVtXSA9PiBbZnNk YXggcG1lbV1bZnNkYXggcmF3XQ0KPiA+ICAgICAgICAgICAgICAgRE1fVFlQRV9EQVhfQklPX0JB U0VEICAgICAgIERNX1RZUEVfQklPX0JBU0VEDQo+ID4gDQo+ID4gYnV0IHRoZXNlIHdpbGwgYm90 aCBzdWNjZWVkOg0KPiA+IA0KPiA+ICBkbS1saW5lYXI6IFtmc2RheCBwbWVtXVticmQgcmFtZGlz a10gPT4gW2ZzZGF4IHBtZW1dW2ZzZGF4IHJhd10NCj4gPiAgICAgICAgICAgICAgICAgRE1fVFlQ RV9CSU9fQkFTRUQgICAgICAgIERNX1RZUEVfQklPX0JBU0VEDQo+ID4gDQo+ID4gIGRtLWxpbmVh cjogW2ZzZGF4IHBtZW1dW2ZzZGF4IHJhd10gPT4gW2ZzZGF4IHBtZW1dW2ZzZGF4IHBtZW1dDQo+ ID4gICAgICAgICAgICAgICAgIERNX1RZUEVfQklPX0JBU0VEICAgICAgICBETV9UWVBFX0RBWF9C SU9fQkFTRUQNCj4gDQo+IFNvIHdlIGFsbG93IDIgb2YgdGhlIDMgdHJhbnNpdGlvbnMsIGJ1dCB0 aGUgcmVhc29uIHRoYXQgd2UgZGlzYWxsb3cgdGhlIHRoaXJkDQo+IGlzbid0IGZ1bGx5IGNsZWFy IHRvIG1lLg0KDQpJIG5lZWQgdG8gcmVmcmVzaCBteSBtZW1vcnkgZm9yIHRoZSBjb2RlLCBidXQg aGVyZSBpcyB0aGUgaW50ZW50Lg0KaHR0cHM6Ly9sa21sLm9yZy9sa21sLzIwMTYvNi8yMi8xMDAw DQpodHRwczovL2xrbWwub3JnL2xrbWwvMjAxNi82LzIyLzk5OQ0KDQoNCj4gPiA+ICBkbS1saW5l YXI6IFtmc2RheCBwbWVtXVtmc2RheCByYXddID0+IFtmc2RheCBwbWVtXVtmc2RheCBwbWVtXQ0K PiA+ID4gIAkJRE1fVFlQRV9CSU9fQkFTRUQgICAgICAgIERNX1RZUEVfREFYX0JJT19CQVNFRA0K PiA+ID4gDQo+ID4gPiBUaGlzIHNlZW1zIGFyYml0cmFyeSwgYXMgcmVhbGx5IHRoZSBjaG9pY2Ug b24gd2hldGhlciB0byB1c2UgREFYIGhhcHBlbnMgYXQNCj4gPiA+IGZpbGVzeXN0ZW0gbW91bnQg dGltZS4gIFRoZXJlJ3Mgbm8gZ3VhcmFudGVlIHRoYXQgdGhlIGluIHRoZSBmaXJzdCBjYXNlDQo+ ID4gPiAoZG91YmxlIGZzZGF4IHBtZW0pIHdlIHdlcmUgdXNpbmcgdGhlIGRheCBtb3VudCBvcHRp b24gd2l0aCBvdXIgZmlsZQ0KPiA+ID4gc3lzdGVtLg0KPiA+ID4gDQo+ID4gPiBJbnN0ZWFkLCBn ZXQgcmlkIG9mIERNX1RZUEVfREFYX0JJT19CQVNFRCBhbmQgYWxsIHRoZSBzcGVjaWFsIGNhc2lu ZyBhcm91bmQNCj4gPiA+IGl0LCBhbmQgaW5zdGVhZCBtYWtlIHRoZSByZXF1ZXN0IHF1ZXVlJ3Mg UVVFVUVfRkxBR19EQVggYmUgb3VyIG9uZSBzb3VyY2UNCj4gPiA+IG9mIHRydXRoLiAgSWYgdGhp cyBpcyBzZXQsIHdlIGNhbiB1c2UgREFYLCBhbmQgaWYgbm90LCBub3QuICBXZSBrZWVwIHRoaXMN Cj4gPiA+IHVwIHRvIGRhdGUgaW4gdGFibGVfbG9hZCgpIGFzIHRoZSB0YWJsZSBjaGFuZ2VzLiAg QXMgd2l0aCByZWd1bGFyIGJsb2NrDQo+ID4gPiBkZXZpY2VzIHRoZSBmaWxlc3lzdGVtIHdpbGwg dGhlbiBrbm93IGF0IG1vdW50IHRpbWUgd2hldGhlciBEQVggaXMgYQ0KPiA+ID4gc3VwcG9ydGVk IG1vdW50IG9wdGlvbiBvciBub3QuDQo+ID4gDQo+ID4gSWYgeW91IGRvbid0IHRoaW5rIHlvdSBu ZWVkIHRoaXMgc3BlY2lhbGl6YXRpb24gdGhhdCBpcyBmaW5lLi4gYnV0IERNDQo+ID4gZGV2aWNl cyBzdXBwb3J0aW5nIHN1c3BlbmRpbmcgKGFzIHBhcnQgb2YgdGFibGUgcmVsb2Fkcykgc28gaXMg dGhlcmUgYW55DQo+ID4gcmlzayB0aGF0IHRoZXJlIHdpbGwgYmUgaW5mbGlnaHQgSU8gKHNheSBp ZiBzb21lb25lIGRpZCAnZG1zZXR1cCBzdXNwZW5kDQo+ID4gLS1ub2ZsdXNoJykuLiBhbmQgdGhl biB1cG9uIHJlbG9hZCB0aGUgZGV2aWNlIHR5cGUgY2hhbmdlZCBvdXQgZnJvbQ0KPiA+IHVuZGVy IHVzLi4gYW55d2F5LCBJIGRvbid0IGhhdmUgYWxsIHRoZSBQTUVNIERBWCBzdHVmZiBwYWdlZCBi YWNrIGludG8NCj4gPiBteSBoZWFkIHlldC4NCj4gPiANCj4gPiBCdXQgdGhpcyBqdXN0IHNlZW1z IGxpa2Ugd2UgcmVhbGx5IHNob3VsZG4ndCBiZSBhbGxvd2luZyB0aGUNCj4gPiB0cmFuc2l0aW9u IGZyb20gd2hhdCB3YXMgRE1fVFlQRV9EQVhfQklPX0JBU0VEIGJhY2sgdG8gRE1fVFlQRV9CSU9f QkFTRUQNCj4gDQo+IEkgYWRtaXQgSSBkb24ndCBmdWxseSB1bmRlcnN0YW5kIGFsbCB0aGUgd2F5 cyB0aGF0IERNIHN1cHBvcnRzIHN1c3BlbmRpbmcgYW5kDQo+IHJlc3VtaW5nIGRldmljZXMuICBJ cyB0aGVyZSBhY3R1YWxseSBhIGNhc2Ugd2hlcmUgd2UgY2FuIGNoYW5nZSBvdXQgdGhlIERNDQo+ IGRldmljZXMgd2hpbGUgSS9PIGlzIHJ1bm5pbmcsIGFuZCBzb21laG93IGVuZCB1cCB0cnlpbmcg dG8gaXNzdWUgYSBEQVggSS9PIHRvDQo+IGEgZGV2aWNlIHRoYXQgZG9lc24ndCBzdXBwb3J0IERB WD8NCj4gDQo+IFRvc2hpLCBkbyB5b3UgaGF2ZSBhIHRlc3QgY2FzZSB0aGF0IHNob3dzIHRoaXMg c29tZWhvdz8NCg0KTm8sIEkgZGlkIG5vdCB0ZXN0IHN1c3BlbmQvcmVzdW1lIHNpbmNlIEhQRSBz ZXJ2ZXJzIGRvIG5vdCBzdXBwb3J0IGl0Lg0KDQpUaGFua3MsDQotVG9zaGkNCg==