From: Dan Williams <dan.j.williams(a)intel.com>
Sent: Friday, February 1, 2019 5:29 PM
> ...
> The "size" and "mode" still don't look right, but the
improvement is that
> now I can see a good descriptive "name", which I suppose is retrieved
> from Hyper-V.
Mode is right, there is no way for Hyper-V to create Linux fsdax mode
namespaces it requires some setup using variables only Linux knows.
Can you send the output of:
ndctl read-labels -j all
The output is from a kernel built with the libnvdimm-pending branch plus
the one-line patch (label->flags &= ~NSLABEL_FLAG_LOCAL) in
init_active_labels():
root@decui-gen2-u1904:~# ndctl read-labels -j all
[
{
"dev":"nmem1",
"index":[
{
"signature":"NAMESPACE_INDEX",
"major":1,
"minor":2,
"labelsize":256,
"seq":1,
"nslot":2
},
{
"signature":"NAMESPACE_INDEX",
"major":1,
"minor":2,
"labelsize":256,
"seq":2,
"nslot":2
}
],
"label":[
{
"uuid":"c258aaab-f72b-e546-bfa5-be5e07761dbc",
"name":"Microsoft Hyper-V NVDIMM 1 Label",
"slot":0,
"position":0,
"nlabel":1,
"isetcookie":708891662257476870,
"lbasize":0,
"dpa":0,
"rawsize":137438953472,
"type_guid":"79d3f066-f3b4-7440-ac43-0d3318b78cdb",
"abstraction_guid":"00000000-0000-0000-0000-000000000000"
}
]
},
{
"dev":"nmem0",
"index":[
{
"signature":"NAMESPACE_INDEX",
"major":1,
"minor":2,
"labelsize":256,
"seq":1,
"nslot":2
},
{
"signature":"NAMESPACE_INDEX",
"major":1,
"minor":2,
"labelsize":256,
"seq":2,
"nslot":2
}
],
"label":[
{
"uuid":"9f0497a7-4453-7c40-ad35-21a791e00345",
"name":"Microsoft Hyper-V NVDIMM 0 Label",
"slot":0,
"position":0,
"nlabel":1,
"isetcookie":708891619307803909,
"lbasize":0,
"dpa":0,
"rawsize":34359738368,
"type_guid":"79d3f066-f3b4-7440-ac43-0d3318b78cdb",
"abstraction_guid":"00000000-0000-0000-0000-000000000000"
}
]
}
]
read 2 nmems
> With Ubuntu 19.04 (4.18.0-11-generic), I get this:
> (Note: the "mode" and "size" are correct. The "uuid"
is different from
> the above "9f0497a7-4453-7c40-ad35-21a791e00345" -- this is weird.)
>
> root@decui-gen2-u1904:~# ndctl list
> [
> {
> "dev":"namespace1.0",
> "mode":"raw",
> "size":137438953472,
> "blockdev":"pmem1"
> },
> {
> "dev":"namespace0.0",
> "mode":"fsdax",
> "map":"dev",
> "size":33820770304,
> "uuid":"35018886-397e-4fe7-a348-0a4d16eec44d",
> "blockdev":"pmem0"
> }
> ]
This is because the Ubuntu kernel has the bug that causes _LSR to fail
so Linux falls back to a namespace defined by the region boundary. On
that namespace there is an "fsdax" info block located at the region
base +4K. That info block is tagged with the uuid of
"35018886-397e-4fe7-a348-0a4d16eec44d".
Thanks for the explanation!
> I'm trying to find out the correct solution. I apprecite
your insights!
It's a mess. First we need to figure out whether the label is actually
specifying a size of zero, or there is some other bug.
I agree.
However, the next problem is going to be adding "fsdax"
mode support
on top of the read-only defined namespaces. The ndctl reconfiguration
flow:
ndctl create-namespace -e namespace0.0 -m fsdax -f
...will likely fail because deleting the previous namespace in the
labels is part of that flow. It's always that labels are writable.
Honestly, the quickest path to something functional for Linux is to
simply delete the _LSR support and use raw mode defined namespaces.
Why have labels if they are read-only and the region is sufficient for
defining boundaries?
Just now Hyper-V team confirmed _LSW is not supported.
But with Ubuntu 19.04 kernel (4.18.0-11-generic), I'm able to run the commands
without any issue:
root@decui-gen2-u1904:~# ndctl list
[
{
"dev":"namespace1.0",
"mode":"raw",
"size":137438953472,
"blockdev":"pmem1"
},
{
"dev":"namespace0.0",
"mode":"fsdax",
"map":"dev",
"size":33820770304,
"uuid":"35018886-397e-4fe7-a348-0a4d16eec44d",
"blockdev":"pmem0"
}
]
root@decui-gen2-u1904:~# ndctl destroy-namespace "namespace0.0"
Error: namespace0.0 is active, specify --force for re-configuration
error destroying namespaces: Device or resource busy
destroyed 0 namespaces
root@decui-gen2-u1904:~# ndctl destroy-namespace "namespace0.0" --force
destroyed 1 namespace
root@decui-gen2-u1904:~# ndctl list
[
{
"dev":"namespace1.0",
"mode":"raw",
"size":137438953472,
"blockdev":"pmem1"
}
]
root@decui-gen2-u1904:~# ndctl create-namespace -e namespace0.0 -m fsdax -f
{
"dev":"namespace0.0",
"mode":"fsdax",
"map":"dev",
"size":"31.50 GiB (33.82 GB)",
"uuid":"9e4e819b-e2eb-4796-8f9e-15f96f63b5c2",
"sector_size":512,
"blockdev":"pmem0",
"numa_node":1
}
root@decui-gen2-u1904:~# ndctl list
[
{
"dev":"namespace1.0",
"mode":"raw",
"size":137438953472,
"blockdev":"pmem1"
},
{
"dev":"namespace0.0",
"mode":"fsdax",
"map":"dev",
"size":33820770304,
"uuid":"9e4e819b-e2eb-4796-8f9e-15f96f63b5c2",
"blockdev":"pmem0"
}
]
The above commands can also run fine with an upstream kernel that
doesn't have
11189c1089da ("acpi/nfit: Fix command-supported detection")
or
1194c4133195 ("nfit: Add Hyper-V NVDIMM DSM command set to white list")
Thanks
-- Dexuan