lkml.org 
[lkml]   [2017]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC PATCH] dax: add badblocks check to Device DAX
On Wed, May 3, 2017 at 4:36 PM, Kani, Toshimitsu <toshi.kani@hpe.com> 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 <dan.j.williams@intel.
>> > co
>> > m> wrote:
>> > > On Wed, May 3, 2017 at 3:41 PM, Kani, Toshimitsu <toshi.kani@hpe.
>> > > co
>> > > m> 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/regio
>> > > n1
>> > > /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/region1
>> > /d
>> > ax1.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/dax0.
>> 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"

>
> 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/dax0.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.

\
 
 \ /
  Last update: 2017-05-04 04:01    [W:0.170 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site