From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from g2t2354.austin.hpe.com (g2t2354.austin.hpe.com [15.233.44.27]) (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 CEBB620958969 for ; Wed, 5 Jul 2017 18:17:52 -0700 (PDT) From: "Kani, Toshimitsu" Subject: Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges Date: Thu, 6 Jul 2017 01:17:45 +0000 Message-ID: <1499303324.2042.7.camel@hpe.com> References: <149875877608.10031.17813337234536358002.stgit@dwillia2-desk3.amr.corp.intel.com> <149875884190.10031.6179599135820559644.stgit@dwillia2-desk3.amr.corp.intel.com> <595552F5.5040008@hpe.com> <59556E37.80808@hpe.com> <595580A6.9000004@hpe.com> <595589CF.5010605@hpe.com> <1499297819.2042.5.camel@hpe.com> In-Reply-To: Content-Language: en-US Content-ID: MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: "dan.j.williams@intel.com" Cc: "x86@kernel.org" , "jack@suse.cz" , "linux-nvdimm@lists.01.org" , "mawilcox@microsoft.com" , "linux-kernel@vger.kernel.org" , "viro@zeniv.linux.org.uk" , "linux-fsdevel@vger.kernel.org" , "hch@lst.de" List-ID: T24gV2VkLCAyMDE3LTA3LTA1IGF0IDE3OjA3IC0wNzAwLCBEYW4gV2lsbGlhbXMgd3JvdGU6DQo+ IE9uIFdlZCwgSnVsIDUsIDIwMTcgYXQgNDo0NiBQTSwgS2FuaSwgVG9zaGltaXRzdSA8dG9zaGku a2FuaUBocGUuY29tPg0KPiB3cm90ZToNCj4gPiBPbiBUaHUsIDIwMTctMDYtMjkgYXQgMTg6Mjgg LTA3MDAsIERhbiBXaWxsaWFtcyB3cm90ZToNCiA6DQo+ID4gDQo+ID4gU29ycnkgZm9yIGJlaW5n IGxhdGUgdG8gcmVzcG9uZCwgYnV0IEkgYWdyZWUgd2l0aCBMaW5kYSB0aGF0IHRoaXMNCj4gPiBu YW1pbmcgcG9saWN5IGlzIGxpa2VseSB0byBjb25mdXNlIHVzZXJzLsKgwqBJIGFsc28gY2FyZSBs ZXNzIGFib3V0DQo+ID4gdGhlIGN1cnJlbnQgdXNlcnMgd2hvIHVzZSBtZW1tYXAgb3B0aW9uLsKg wqBUaGlzIGNhc2UgaXMgcG1lbS0NCj4gPiBlbXVsYXRpb24gYW5kIHRoZXkga25vdyB3aGF0IHRo ZXkgYXJlIGRvaW5nLg0KPiA+IA0KPiA+IEFzc3VtaW5nIGJsb2NrIGRldmljZSBpbnRlcmZhY2Ug aXMgbmVlZGVkIChpbiBhZGRpdGlvbiB0byBkZXZpY2UtDQo+ID4gZGF4KSBmb3Igdm9sYXRpbGUg cmFuZ2UgZm9yIHVzZS1jYXNlcyBsaWtlIHN3YXAgZGV2aWNlLCBJIHdvbmRlciBpZg0KPiA+IHVz ZXIgY2FuIGFjdHVhbGx5IHNwZWNpZnkgYSByaWdodCBwbWVtIGRldmljZSBmb3Igc3dhcCBmcm9t IE9TLQ0KPiA+IGluc3RhbGwgR1VJIHdoZW4gYm90aCB2b2xhdGlsZSBhbmQgcGVyc2lzdGVudCBi bG9jayBkZXZpY2VzIGFyZQ0KPiA+IGxpc3RlZCBhcyAvZGV2L3BtZW1OLiAgU29tZXRpbWVzIHdl IGFyZSByZXN0cmljdGVkIHdpdGggR1VJDQo+ID4gbWVudS7CoMKgU29tZSB1c2VycyB1c2UgR1VJ IGFsbCB0aGUgdGltZSBsaWtlIFdpbmRvd3MgYXMgd2VsbC4NCj4gPiANCj4gPiBDYW4gd2UgZGlm ZmVyZW50aWF0ZSB0aGUgbmFtaW5nIGJ5IGFkZGluZyAndicgbGlrZSAncG1lbU52JyAoaWYgeW91 DQo+ID4gY2FuJ3QgZ28gd2l0aCAndm1lbU4nKT/CoMKgSSBkb24ndCB0aGluayBoYXZpbmcgJ3Mn IGZvciBCVFQgd2FzIHRoYXQNCj4gPiBiYWQuIMKgSXQncyBiZWVuIGhlbHBmdWwgdG8gdGVsbCB1 c2VycyB0aGF0IHRoZXNlIHBtZW0gZGV2aWNlcyBhcmUNCj4gPiBub3QgYnl0ZS1hZGRyZXNzYWJs ZS7CoMKgSSBhbHNvIHRoaW5rIHRoYXQgQlRUIGZvciB2b2xhdGlsZSByYW5nZQ0KPiA+IG1ha2Vz IG5vIHNlbnNlICh1bmxlc3MgZW11bGF0ZWQgYXMgcGVyc2lzdGVudCBtZW1vcnkgYnkgbWVtbWFw DQo+ID4gb3B0aW9uKS4NCj4gDQo+IEknbSBtb3JlIHdvcnJpZWQgYWJvdXQgc2VuZGluZyB0aGUg d3Jvbmcgc2lnbmFsIHRoZSBvdGhlciB3YXkuIFRoYXQNCj4gdXNlcnMgYmVsaWV2ZSB0aGF0IHRo ZSAncCcgbWVhbnMgZGVmaW5pdGVseSAicGVyc2lzdGVudCIgd2hlbiB3ZSBoYXZlDQo+IG5vIHdh eSB0byBndWFyYW50ZWUgdGhhdC4NCg0KVGhhdCdzIGEgdmFsaWQgcG9pbnQuICBCdXQgaXNuJ3Qg aXQgdmVuZG9ycycgcmVzcG9uc2liaWxpdHkgdG8NCmd1YXJhbnRlZSBpdCB3aGVuIHRoZWlyIGRl dmljZXMgYXJlIGRlc2NyaWJlZCBhcyBwZXJzaXN0ZW50IGluIG9uZSB3YXkNCm9yIHRoZSBvdGhl ciBpbiBGVz8NCg0KPiBJZiBpdCB3YXMgb25seSBtZW1tYXA9IHRoYXQgd2UgaGFkIHRvIHdvcnJ5 IGFib3V0IHRoYXQgd291bGQgYmUgb25lDQo+IHRoaW5nLCBidXQgd2UgYXBwYXJlbnRseSBoYXZl IHZlbmRvcnMgdGhhdCBhcmUgc2hpcHBpbmcgImU4MjAtdHlwZS0xMg0KPiBtZW1vcnkiIGFzIHRo ZWlyIE5WRElNTSBzb2x1dGlvbiBbMV0uDQoNClR5cGUtMTIgaXMgcGVyc2lzdGVudCBtZW1vcnkg aW4gYSBub24tc3RhbmRhcmQgRlcgaW50ZXJmYWNlLiAgU28sIGl0DQptYWtlcyBzZW5zZSB0byBz aG93IGl0IGFzIHBtZW0uDQoNCj4gV2UndmUgYWxzbyBiZWVuIHNoaXBwaW5nIHRoZSBwb2xpY3kg dGhhdCAncG1lbScgbWF5IGZyb250IGEgdm9sYXRpbGUNCj4gcmFuZ2UgZXZlciBzaW5jZSB2NC44 IChjb21taXQgYzJmMzJhY2RmODQ4ICJhY3BpLCBuZml0OiB0cmVhdCB2aXJ0dWFsDQo+IHJhbWRp c2sgU1BBIGFzIHBtZW0gcmVnaW9uIikuIEF0IGxlYXN0IG5vdyB3ZSBoYXZlIHRoZSAibmRfdm9s YXRpbGUiDQo+IHJlZ2lvbiB0eXBlLiBBbnkgY2hhbmdlIG9mIHRoZSBkZXZpY2UgbmFtZSBub3cg aXMgcG90ZW50aWFsbHkgYQ0KPiByZWdyZXNzaW9uIGZvciBlbnZpcm9ubWVudHMgdGhhdCBhcmUg YWxyZWFkeSBleHBlY3RpbmcgL2Rldi9wbWVtWC4NCg0KSG1tLi4uIEkgdGhvdWdodCB0aGlzIHdh cyBmb3IgbWFwcGluZyBJU08gaW1hZ2UgZm9yIGJvb3RpbmcuICBEb2VzIGl0DQpnZXQgbGlzdGVk IGFzIGEgcmVndWxhciBwbWVtIGRldmljZSBhbmQgYWxsb3cgdXNlciB0byBtb2RpZnkgaXRzDQpj b250ZW50PyAgSSBkb3VidCB0aGlzIGNhc2UgYmVpbmcgdXNlZCB0b2RheSwgdGhvdWdoLiAgKEl0 IHdhcw0KcHJvdG90eXBlZCBvbiBhbiBIUEUgYm94IGFuZCBJIGNhbiBjaGVjayB0aGUgc3RhdHVz IGlmIG5lZWRlZC4pDQoNCj4gQXMgZmFyIGFzIEkga25vdyB0aGVyZSBhcmUgbm8gT1MgaW5zdGFs bGVycyB0aGF0IHVuZGVyc3RhbmQgcG1lbS4gDQoNCkl0J3MgYWN0dWFsbHkgdGhlIG90aGVyIHdh eSBhcm91bmQuICBJdCB3YXMgY2hhbmdlZCBub3QgdG8gbGlzdCBwbWVtDQpkZXZpY2VzIHNpbmNl IE9TIGNhbm5vdCBib290IGZyb20gYSBwbWVtIHlldC4uLg0KDQo+IFdoZW4gdGhleSBkbyBhZGQg c3VwcG9ydCBJIHRoaW5rIGl0IHdvdWxkIGJlIHN0cmFpZ2h0Zm9yd2FyZCB0byBhdm9pZA0KPiBj b25mdXNpb24gYW5kIGZpbHRlciAidm9sYXRpbGUiIGhvc3RlZCBwbWVtIGRldmljZXMgZnJvbSB0 aGUgaW5zdGFsbA0KPiB0YXJnZXQgbGlzdC4gSSBkb24ndCBzZWUgdGhpcyBiZWluZyBtdWNoIGRp ZmZlcmVudCBmcm9tIHRoZSBjb25mdXNpb24NCj4gd2hlbiB1c2VycyBjYW4gbm90IGRpZmZlcmVu dGlhdGUgdGhlaXIgJ3NkJyBkZXZpY2UgYmV0d2VlbiBVU0IgYW5kDQo+IFNBVEEuIA0KDQpSaWdo dCwgc3VjaCBjaGFuZ2VzIGNhbiBiZSBtYWRlLiAgSXQgd2FzIGp1c3QgYW4gZXhhbXBsZSB0aGF0 IHR5cGljYWwNCnVzZS1jYXNlcyB0b2RheSBkbyBub3QgcmVxdWlyZSBhZGRpdGlvbmFsIHN0ZXAg dG8gY2hlY2sgcGVyc2lzdGVuY2Ugb2YNCmJsb2NrIGRldmljZXMuDQoNCj4gV2UgaGF2ZSBzeW1s aW5rcyBpbiAvZGV2L2Rpc2svYnkqIHRvIG1ha2UgaXQgZWFzaWVyIHRvIGlkZW50aWZ5DQo+IHN0 b3JhZ2UgZGV2aWNlcywgSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBhZGQgdWRldiBydWxlcyBm b3INCj4gaWRlbnRpZnlpbmcgdm9sYXRpbGUgcG1lbSBhbmQgbm90IHRyeSB0byBkaWZmZXJlbnRp YXRlIHRoaXMgaW4gdGhlDQo+IGRlZmF1bHQga2VybmVsIGRldmljZSBuYW1lLg0KDQpJIGFtIG5v dCBzdXJlIHdoYXQgbWlnaHQgYmUgYSBnb29kIHdheSwgYnV0IEkgYW0gY29uY2VybmVkIGJlY2F1 c2UgYQ0Kc2luZ2xlIGJsb2NrIGRldmljZSBuYW1pbmcgZG8gbm90IHJlcHJlc2VudCBib3RoIHZv bGF0aWxlIGFuZA0KcGVyc2lzdGVudCBtZWRpYSB0b2RheS4NCg0KVGhhbmtzLA0KLVRvc2hpDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTGludXgt bnZkaW1tIG1haWxpbmcgbGlzdApMaW51eC1udmRpbW1AbGlzdHMuMDEub3JnCmh0dHBzOi8vbGlz dHMuMDEub3JnL21haWxtYW4vbGlzdGluZm8vbGludXgtbnZkaW1tCg== From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752703AbdGFBTf (ORCPT ); Wed, 5 Jul 2017 21:19:35 -0400 Received: from g2t2354.austin.hpe.com ([15.233.44.27]:43818 "EHLO g2t2354.austin.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752440AbdGFBTd (ORCPT ); Wed, 5 Jul 2017 21:19:33 -0400 From: "Kani, Toshimitsu" To: "dan.j.williams@intel.com" CC: "linux-kernel@vger.kernel.org" , "hch@lst.de" , "viro@zeniv.linux.org.uk" , "x86@kernel.org" , "mawilcox@microsoft.com" , "linux-nvdimm@lists.01.org" , "Knippers, Linda" , "linux-fsdevel@vger.kernel.org" , "jack@suse.cz" Subject: Re: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges Thread-Topic: [PATCH v4 12/16] libnvdimm, nfit: enable support for volatile ranges Thread-Index: AQHS8QGnKkts09hmeUykqHaORyWjLKI8N3yAgAAW54CAAAmYgIAACV8AgAAGVgCAAAR7gIAAAckAgAACPYCAAAHVAIAAAn8AgAAEW4CAACVlAIAJTuiAgAAIlICAABEOAA== Date: Thu, 6 Jul 2017 01:17:45 +0000 Message-ID: <1499303324.2042.7.camel@hpe.com> References: <149875877608.10031.17813337234536358002.stgit@dwillia2-desk3.amr.corp.intel.com> <149875884190.10031.6179599135820559644.stgit@dwillia2-desk3.amr.corp.intel.com> <595552F5.5040008@hpe.com> <59556E37.80808@hpe.com> <595580A6.9000004@hpe.com> <595589CF.5010605@hpe.com> <1499297819.2042.5.camel@hpe.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: intel.com; dkim=none (message not signed) header.d=none;intel.com; dmarc=none action=none header.from=hpe.com; x-originating-ip: [15.203.227.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;DF4PR84MB0075;7:DoyMmZ0yEt3eGoKxS9ymWZrJWVy2/JOzPClRkVIz9U4NK9/9KEq0wUcgrwZZ2L3JDj0jADdM8G6+LPwKj2AVKozulidCbn9FVnfHS7pe1LePoGFt4AMpFUeh1jdQUSDShxlzja1Oa/MVeaRIAz1Szt6A76cm7xTQjnVCXmrgR3Nt/6DGV0shrdTwxmLLyfbnUsgSI67ts0z8fmXDM7zk4g1smkM1LO2Q2Qd8R1+g+9HGT8BN4CC4OObfUnaulyRX79eOUGYuKVi+vawti5cj28brBAn8FCaFxRzjLFvFJhalrIpObqMlgUdpVRwtlexDo5+d9hz8psVf0ttX4K1B6w7koE+A6tCG/P9NJZHK+1tcMXFMfjwA2D7jS91n/PTBTWiuyWOzPVAW6p/Om1ngPGDfeBPUzfxdmchdTp1wm/Mu+uP/RhQZC/EQPac191nQyh021rvfRB8lMXBRUQ0LlnRwZiGNiraLqDKVjgV/RsdOw451fh0O78BhQKOoBMBscVH6+N+t9RqKn5FCxfBW0dAl3Mpsj28MOSZMeo3GqPxx9Ba/jc95xt0sNxFHKDbDW5qaKxZpG71qmQjtfermApCJRkGb9dzvMYwyn1ZAcP4ZavHI7XdPthnRq0yxByqTbK3b1/zdYAy4WQRl10kzzyRNCI/JGWG5ePViaPPnu0gzALCtylUZwFZnDrVHHF/NRFZgFD+AX0uagezqFmofWScUw+Cv/axllTX2dQVxwxb7bCOboAvn+L4onOXOvrQzFrmUmx2L0fXsmPm6XOyi8tAHEFqY1RhwD9M0cWtRI5M= x-forefront-antispam-report: SFV:SKI;SCL:-1SFV:NSPM;SFS:(10019020)(6009001)(39850400002)(39860400002)(39410400002)(39400400002)(39840400002)(39450400003)(24454002)(377424004)(377454003)(2950100002)(38730400002)(305945005)(6916009)(2906002)(8936002)(7736002)(8676002)(81166006)(6246003)(110136004)(53936002)(4326008)(103116003)(53546010)(189998001)(6506006)(25786009)(36756003)(2900100001)(229853002)(6486002)(93886004)(86362001)(33646002)(2501003)(2351001)(77096006)(3660700001)(478600001)(66066001)(76176999)(3280700002)(50986999)(14454004)(54356999)(102836003)(6436002)(6116002)(8666007)(3846002)(5660300001)(6512007)(54906002)(5640700003);DIR:OUT;SFP:1102;SCL:1;SRVR:DF4PR84MB0075;H:DF4PR84MB0105.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;MLV:sfv;LANG:en; x-ms-office365-filtering-correlation-id: abe6f33a-7dfd-4a2b-0bc9-08d4c40ccec1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(48565401081)(300000503095)(300135400095)(2017052603031)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095);SRVR:DF4PR84MB0075; x-ms-traffictypediagnostic: DF4PR84MB0075: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861)(133145235818549)(236129657087228)(225559137633274)(247924648384137); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095);SRVR:DF4PR84MB0075;BCL:0;PCL:0;RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095);SRVR:DF4PR84MB0075; x-forefront-prvs: 03607C04F0 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2017 01:17:45.2641 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: DF4PR84MB0075 X-OriginatorOrg: hpe.com Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by nfs id v661Jg5U023937 On Wed, 2017-07-05 at 17:07 -0700, Dan Williams wrote: > On Wed, Jul 5, 2017 at 4:46 PM, Kani, Toshimitsu > wrote: > > On Thu, 2017-06-29 at 18:28 -0700, Dan Williams wrote: : > > > > Sorry for being late to respond, but I agree with Linda that this > > naming policy is likely to confuse users.  I also care less about > > the current users who use memmap option.  This case is pmem- > > emulation and they know what they are doing. > > > > Assuming block device interface is needed (in addition to device- > > dax) for volatile range for use-cases like swap device, I wonder if > > user can actually specify a right pmem device for swap from OS- > > install GUI when both volatile and persistent block devices are > > listed as /dev/pmemN. Sometimes we are restricted with GUI > > menu.  Some users use GUI all the time like Windows as well. > > > > Can we differentiate the naming by adding 'v' like 'pmemNv' (if you > > can't go with 'vmemN')?  I don't think having 's' for BTT was that > > bad.  It's been helpful to tell users that these pmem devices are > > not byte-addressable.  I also think that BTT for volatile range > > makes no sense (unless emulated as persistent memory by memmap > > option). > > I'm more worried about sending the wrong signal the other way. That > users believe that the 'p' means definitely "persistent" when we have > no way to guarantee that. That's a valid point. But isn't it vendors' responsibility to guarantee it when their devices are described as persistent in one way or the other in FW? > If it was only memmap= that we had to worry about that would be one > thing, but we apparently have vendors that are shipping "e820-type-12 > memory" as their NVDIMM solution [1]. Type-12 is persistent memory in a non-standard FW interface. So, it makes sense to show it as pmem. > We've also been shipping the policy that 'pmem' may front a volatile > range ever since v4.8 (commit c2f32acdf848 "acpi, nfit: treat virtual > ramdisk SPA as pmem region"). At least now we have the "nd_volatile" > region type. Any change of the device name now is potentially a > regression for environments that are already expecting /dev/pmemX. Hmm... I thought this was for mapping ISO image for booting. Does it get listed as a regular pmem device and allow user to modify its content? I doubt this case being used today, though. (It was prototyped on an HPE box and I can check the status if needed.) > As far as I know there are no OS installers that understand pmem. It's actually the other way around. It was changed not to list pmem devices since OS cannot boot from a pmem yet... > When they do add support I think it would be straightforward to avoid > confusion and filter "volatile" hosted pmem devices from the install > target list. I don't see this being much different from the confusion > when users can not differentiate their 'sd' device between USB and > SATA. Right, such changes can be made. It was just an example that typical use-cases today do not require additional step to check persistence of block devices. > We have symlinks in /dev/disk/by* to make it easier to identify > storage devices, I think it makes sense to add udev rules for > identifying volatile pmem and not try to differentiate this in the > default kernel device name. I am not sure what might be a good way, but I am concerned because a single block device naming do not represent both volatile and persistent media today. Thanks, -Toshi