From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755539AbdEDOIt (ORCPT ); Thu, 4 May 2017 10:08:49 -0400 Received: from g9t5008.houston.hpe.com ([15.241.48.72]:35252 "EHLO g9t5008.houston.hpe.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755112AbdEDOIY (ORCPT ); Thu, 4 May 2017 10:08:24 -0400 From: "Kani, Toshimitsu" To: "dan.j.williams@intel.com" CC: "linux-kernel@vger.kernel.org" , "dave.jiang@intel.com" , "linux-nvdimm@lists.01.org" Subject: Re: [RFC PATCH] dax: add badblocks check to Device DAX Thread-Topic: [RFC PATCH] dax: add badblocks check to Device DAX Thread-Index: AQHSxCJYsIkXTJcozUeBmwgaJMx1HaHiwjaAgAAEtwCAAAXrgIAAJiGAgAAy3QCAAA6sAIAAAvMAgAAEj4CAAATXAIAAAvWAgAAokwCAAMsNgA== Date: Thu, 4 May 2017 14:08:12 +0000 Message-ID: <1493906887.30303.57.camel@hpe.com> References: <20170503153103.30756-1-toshi.kani@hpe.com> <1493827750.30303.44.camel@hpe.com> <1493837209.30303.47.camel@hpe.com> <1493851282.30303.49.camel@hpe.com> <1493853934.30303.51.camel@hpe.com> <1493854569.30303.53.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.219.163.8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1;AT5PR84MB0260;7:64IJeaSApmimyMl6DbQqGt6emeoPaaumd+jQcfI2PwqL08X0k7TOoNz8xB8COlFvJtO+cffSuuKTJdr31kOW/Xbk/1zCiQ4Toi7HTM8WSbZVqHC9IuG70DUG33PcYP92/7XZxrW7/P3b6g/K0Ed2gW0Fjasd/5S0fM0+QUDZ5IIigGPUJA7Xc4s/2+AOfYz15pMudf1BqMUeeXEneOinfHiEige6Ly3KzsQ5HKwI17j83jIK6GjKp1/rXxZ287u9TdYKSaknWxJjnOAfBl0RfkYAze/gHmLOLGNuHhpoP8Jn8CcLQhcKBzBnrRsxXZ1a/PR137BgmfmTnzu+/1FWxQ== x-ms-office365-filtering-correlation-id: 855b0c32-c8e8-42cd-b1e2-08d492f70095 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081);SRVR:AT5PR84MB0260; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227479698468861)(228905959029699); x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(20161123558100)(6072148);SRVR:AT5PR84MB0260;BCL:0;PCL:0;RULEID:;SRVR:AT5PR84MB0260; x-forefront-prvs: 02973C87BC x-forefront-antispam-report: SFV:NSPM;SFS:(10019020)(6009001)(39410400002)(39840400002)(39450400003)(39850400002)(39860400002)(39400400002)(377454003)(377424004)(24454002)(5640700003)(6486002)(6436002)(110136004)(33646002)(6506006)(6246003)(50986999)(4326008)(3280700002)(3660700001)(76176999)(8936002)(38730400002)(53936002)(2501003)(86362001)(478600001)(6512007)(3846002)(5660300001)(2351001)(2906002)(7736002)(305945005)(102836003)(6116002)(93886004)(54356999)(6916009)(66066001)(189998001)(5250100002)(2950100002)(36756003)(53546009)(2900100001)(25786009)(8676002)(229853002)(81166006)(103116003);DIR:OUT;SFP:1102;SCL:1;SRVR:AT5PR84MB0260;H:AT5PR84MB0260.NAMPRD84.PROD.OUTLOOK.COM;FPR:;SPF:None;MLV:sfv;LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2017 14:08:12.7628 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 105b2061-b669-4b31-92ac-24d304d195dc X-MS-Exchange-Transport-CrossTenantHeadersStamped: AT5PR84MB0260 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 mail.home.local id v44EAx8v028294 On Wed, 2017-05-03 at 19:01 -0700, Dan Williams wrote: > On Wed, May 3, 2017 at 4:36 PM, Kani, Toshimitsu > wrote: > > On Wed, 2017-05-03 at 17:25 -0600, Toshi Kani wrote: > > > On Wed, 2017-05-03 at 16:08 -0700, Dan Williams wrote: > > > > On Wed, May 3, 2017 at 3:51 PM, Dan Williams > > > > wrote: > > > > > On Wed, May 3, 2017 at 3:41 PM, Kani, Toshimitsu > > > > > wrote: > > > > > > On Wed, 2017-05-03 at 14:48 -0700, Dan Williams wrote: > > > > > >  : > > > > > > > > > > I believe we already have all the data needed to calculate > > > > > the data offset. Given the following sysfs path: > > > > > > > > > >     /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/r > > > > > egion1/dax1.1/dax/dax1.0 > > > > > > > > > > ...we can find the associated namespace device from that > > > > > dax1.1. > > > > > From there we have the base address of the namespace and the > > > > > size device-dax instance. > > > > > > > > > >     device_dax_data_offset == namespace_base + namespace_size > > > > > - > > > > > device_dax_size > > > > > > > > Dave reminds me that we do have the data offset of the device- > > > > dax instance at the libnvdimm level: > > > > > > > >     /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/reg > > > > ion1/dax1.1/resource > > > > > > > > ...in this example, which maps to ndctl_dax_get_resource(). > > > > > > Thanks for the info!  I noticed why I did not catch this info > > > before. > > > > > > # ll /dev/dax* > > > crw------- 1 root root 251, 3 May  3 04:28 /dev/dax0.0 > > > > > > # pwd > > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region0/d > > > ax0.0 > > > > > > # grep . * > > > align:2097152 > > > devtype:nd_dax > > > modalias:nd:t7 > > > mode:none > > > numa_node:0 > > > grep: power: Is a directory > > > grep: resource: No such device or address > > > grep: size: No such device or address > > > grep: subsystem: Is a directory > > > uevent:DEVTYPE=nd_dax > > > uevent:MODALIAS=nd:t7 > > > > > > But I noticed that "resource" and "size" that are under > > > ".../region0/dax0.1" work.  Is this intended? > > You mean that region0/dax0.1 and region0/dax0.1/dax/dax0.0 are > functional, but region0/dax0.0 is not? Yes, that is expected the > libnvdimm "struct nd_dax" device is on a different device numbering > scheme than the "struct dev_dax" instance. Depending on load and > namespace reconfiguration order you can expect those names to not > match. The dev_dax instance name is "dax region id"."sub-division > instance" Oh, I see. You are right. Looks like I can use the symbolic link under "class/dax" to avoid this numbering issue. # ll /sys/class/dax/dax0.0 lrwxrwxrwx 1 root root 0 May  4 02:55 /sys/class/dax/dax0.0 -> ../../devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region0/dax0.1 /dax/dax0.0 > > > > Here is an output from dax0.1 (I removed the size value).  Noticed > > that mode is different. > > > > # pwd > > /sys/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region0/dax > > 0.1 > > > > # grep . * > > align:2097152 > > grep: dax: Is a directory > > grep: dax_region: Is a directory > > devtype:nd_dax > > grep: driver: Is a directory > > modalias:nd:t7 > > mode:pmem > > namespace:namespace0.0 > > numa_node:0 > > grep: power: Is a directory > > resource:0x250200000 > > size:(size value) > > grep: subsystem: Is a directory > > uevent:DEVTYPE=nd_dax > > uevent:DRIVER=dax_pmem > > uevent:MODALIAS=nd:t7 > > uuid:8c71811f-260d-4788-8487-db88d829d393 > > The "mode" in this instance is the mode for the struct page > allocation, i.e. whether it is coming from main memory "mem" or the > persistent memory itself "pmem" in this case. Right. I was totally confused by the numbering of these files... Thanks! -Toshi