人工成本不断上升而生产能未能最大化
___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [v6,2/8] dmaengine: Add DMA_MEMCPY_SG transaction op
On Mon, Nov 13, 2017 at 09:28:46AM +0100, Stefan Roese wrote: > Hi Vinod, > > On 31.08.2017 12:57, Robin Murphy wrote: > >On 30/08/17 19:25, Dave Jiang wrote: > >>On 08/30/2017 11:18 AM, Robin Murphy wrote: > >>>On 25/08/17 21:59, Dave Jiang wrote: > Adding a dmaengine transaction operation that allows copy to/from a > scatterlist and a flat buffer. > >>> > >>>Apologies if I'm late to the party, but doesn't DMA_SG already cover > >>>this use-case? As far as I can see, all this does is save the caller > >>>from setting up a single-entry scatterlist to describe the buffer - even > >>>if such a simplified interface is justified it seems like something that > >>>could be implemented as a wrapper around dmaengine_prep_dma_sg() rather > >>>than the providers having to implement a whole extra callback. > >>> > >> > >>DMA_SG is queued to be removed in 4.14. There is no in kernel consumer > >>for the code. > > > >Ah, I see, that's what I was missing. So we're effectively just > >replacing that interface with a more pragmatic alternative - that makes > >sense. > > What are the plans with this new DMA_MEMCPY_SG interface? When will it > hit mainline or is something missing? The old one was removed in 4.14 so if you have a usage feel free to send a patch to add this with usage. Thanks -- ~Vinod ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [v6,2/8] dmaengine: Add DMA_MEMCPY_SG transaction op
Hi Vinod, On 15.11.2017 16:52, Vinod Koul wrote: On Mon, Nov 13, 2017 at 09:28:46AM +0100, Stefan Roese wrote: Hi Vinod, On 31.08.2017 12:57, Robin Murphy wrote: On 30/08/17 19:25, Dave Jiang wrote: On 08/30/2017 11:18 AM, Robin Murphy wrote: On 25/08/17 21:59, Dave Jiang wrote: Adding a dmaengine transaction operation that allows copy to/from a scatterlist and a flat buffer. Apologies if I'm late to the party, but doesn't DMA_SG already cover this use-case? As far as I can see, all this does is save the caller >from setting up a single-entry scatterlist to describe the buffer - even if such a simplified interface is justified it seems like something that could be implemented as a wrapper around dmaengine_prep_dma_sg() rather than the providers having to implement a whole extra callback. DMA_SG is queued to be removed in 4.14. There is no in kernel consumer for the code. Ah, I see, that's what I was missing. So we're effectively just replacing that interface with a more pragmatic alternative - that makes sense. What are the plans with this new DMA_MEMCPY_SG interface? When will it hit mainline or is something missing? The old one was removed in 4.14 so if you have a usage feel free to send a patch to add this with usage. No, its not the "old one" (DMA_SG) but the "new one" (DMA_MEMCPY_SG) I'm referring to (this email thread). My impression was, that this new interface has (or will get) in-kernel users and will be pulled at some time. Thanks, Stefan ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [v6,2/8] dmaengine: Add DMA_MEMCPY_SG transaction op
On 11/15/2017 09:13 AM, Stefan Roese wrote: > Hi Vinod, > > On 15.11.2017 16:52, Vinod Koul wrote: >> On Mon, Nov 13, 2017 at 09:28:46AM +0100, Stefan Roese wrote: >>> Hi Vinod, >>> >>> On 31.08.2017 12:57, Robin Murphy wrote: On 30/08/17 19:25, Dave Jiang wrote: > On 08/30/2017 11:18 AM, Robin Murphy wrote: >> On 25/08/17 21:59, Dave Jiang wrote: >>> Adding a dmaengine transaction operation that allows copy to/from a >>> scatterlist and a flat buffer. >> >> Apologies if I'm late to the party, but doesn't DMA_SG already cover >> this use-case? As far as I can see, all this does is save the caller > >from setting up a single-entry scatterlist to describe the buffer - even >> if such a simplified interface is justified it seems like something that >> could be implemented as a wrapper around dmaengine_prep_dma_sg() rather >> than the providers having to implement a whole extra callback. >> > > DMA_SG is queued to be removed in 4.14. There is no in kernel consumer > for the code. Ah, I see, that's what I was missing. So we're effectively just replacing that interface with a more pragmatic alternative - that makes sense. >>> >>> What are the plans with this new DMA_MEMCPY_SG interface? When will it >>> hit mainline or is something missing? >> >> The old one was removed in 4.14 so if you have a usage feel free to send a >> patch to add this with usage. > > No, its not the "old one" (DMA_SG) but the "new one" (DMA_MEMCPY_SG) > I'm referring to (this email thread). My impression was, that this > new interface has (or will get) in-kernel users and will be pulled at > some time. > Decided to hold off on the submission for now. If you need it and have an upstream consumer for it, feel free to push the change. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
[PATCH 1/3] libnvdimm: Add of_node to region and bus descriptors
We want to be able to cross reference the region and bus devices with the device tree node that they were spawned from. libNVDIMM handles creating the actual devices for these internally, so we need to pass in a pointer to the relevant node in the descriptor. Signed-off-by: Oliver O'Halloran --- drivers/nvdimm/bus.c | 1 + drivers/nvdimm/region_devs.c | 1 + include/linux/libnvdimm.h| 3 +++ 3 files changed, 5 insertions(+) diff --git a/drivers/nvdimm/bus.c b/drivers/nvdimm/bus.c index 0a5e6cd758fe..d6f94303ae44 100644 --- a/drivers/nvdimm/bus.c +++ b/drivers/nvdimm/bus.c @@ -358,6 +358,7 @@ struct nvdimm_bus *nvdimm_bus_register(struct device *parent, nvdimm_bus->dev.release = nvdimm_bus_release; nvdimm_bus->dev.groups = nd_desc->attr_groups; nvdimm_bus->dev.bus = &nvdimm_bus_type; + nvdimm_bus->dev.of_node = nd_desc->of_node; dev_set_name(&nvdimm_bus->dev, "ndbus%d", nvdimm_bus->id); rc = device_register(&nvdimm_bus->dev); if (rc) { diff --git a/drivers/nvdimm/region_devs.c b/drivers/nvdimm/region_devs.c index abaf38c61220..4d756d8c8386 100644 --- a/drivers/nvdimm/region_devs.c +++ b/drivers/nvdimm/region_devs.c @@ -992,6 +992,7 @@ static struct nd_region *nd_region_create(struct nvdimm_bus *nvdimm_bus, dev->parent = &nvdimm_bus->dev; dev->type = dev_type; dev->groups = ndr_desc->attr_groups; + dev->of_node = ndr_desc->of_node; nd_region->ndr_size = resource_size(ndr_desc->res); nd_region->ndr_start = ndr_desc->res->start; nd_device_register(dev); diff --git a/include/linux/libnvdimm.h b/include/linux/libnvdimm.h index f8109ddb5ef1..fcd9f521e481 100644 --- a/include/linux/libnvdimm.h +++ b/include/linux/libnvdimm.h @@ -65,12 +65,14 @@ typedef int (*ndctl_fn)(struct nvdimm_bus_descriptor *nd_desc, struct nvdimm *nvdimm, unsigned int cmd, void *buf, unsigned int buf_len, int *cmd_rc); +struct device_node; struct nvdimm_bus_descriptor { const struct attribute_group **attr_groups; unsigned long bus_dsm_mask; unsigned long cmd_mask; struct module *module; char *provider_name; + struct device_node *of_node; ndctl_fn ndctl; int (*flush_probe)(struct nvdimm_bus_descriptor *nd_desc); int (*clear_to_send)(struct nvdimm_bus_descriptor *nd_desc, @@ -112,6 +114,7 @@ struct nd_region_desc { int num_lanes; int numa_node; unsigned long flags; + struct device_node *of_node; }; struct device; -- 2.9.5 ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
[PATCH 3/3] powerpc/powernv: Create platform devs for nvdimm buses
Scan the devicetree for an nvdimm-bus compatible and create a platform device for them. Signed-off-by: Oliver O'Halloran --- arch/powerpc/platforms/powernv/opal.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c index 65c79ecf5a4d..32df0d44f086 100644 --- a/arch/powerpc/platforms/powernv/opal.c +++ b/arch/powerpc/platforms/powernv/opal.c @@ -831,6 +831,9 @@ static int __init opal_init(void) /* Create i2c platform devices */ opal_pdev_init("ibm,opal-i2c"); + /* Handle non-volatile memory devices */ + opal_pdev_init("nvdimm-bus"); + /* Setup a heatbeat thread if requested by OPAL */ opal_init_heartbeat(); -- 2.9.5 ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
[PATCH 2/3] libnvdimm: Add a device-tree interface
A fairly bare-bones set of device-tree bindings so libnvdimm can be used on powerpc and other device-tree based platforms. Cc: devicet...@vger.kernel.org Signed-off-by: Oliver O'Halloran --- .../devicetree/bindings/nvdimm/nvdimm-bus.txt | 69 +++ MAINTAINERS| 8 + drivers/nvdimm/Kconfig | 10 + drivers/nvdimm/Makefile| 1 + drivers/nvdimm/of_nvdimm.c | 202 + 5 files changed, 290 insertions(+) create mode 100644 Documentation/devicetree/bindings/nvdimm/nvdimm-bus.txt create mode 100644 drivers/nvdimm/of_nvdimm.c diff --git a/Documentation/devicetree/bindings/nvdimm/nvdimm-bus.txt b/Documentation/devicetree/bindings/nvdimm/nvdimm-bus.txt new file mode 100644 index ..491e7c4900ed --- /dev/null +++ b/Documentation/devicetree/bindings/nvdimm/nvdimm-bus.txt @@ -0,0 +1,69 @@ +Device-tree bindings for nonvolatile-memory / NVDIMMs +- + +Non-volatile DIMMs are memory modules used to provide (cacheable) main memory that +retains its contents across power cycles. In more practical terms, they are kind +of storage device where the contents can be accessed by the CPU directly, +rather than indirectly via a storage controller or similar. This can provide +substantial performance improvements for applications designed to take +advantage of in-memory storage. + +This binding provides a way to describe memory regions that should be managed +by an NVDIMM storage driver (libNVDIMM in Linux) and some of the associated +metadata. The binding itself is split into two main parts: A container bus and +its sub-nodes which describe which memory address ranges corresponding to +NVDIMM backed memory. + +Bindings for the container bus: +-- + +Required properties: + - compatible = "nvdimm-bus"; + - ranges; + A blank ranges property is required because the sub-nodes have + addresses in the system's physical address space. + +The use of a container bus is mainly to handle future expansion of the binding. For +comparison the ACPI equivalent of this binding (NFIT) describes: Memory regions, DIMM +control structures, Block mode DIMM control structures, interleave sets, and more. Some +of these structures cross reference each other so everyone should be happier if we keep +it relatively self contained. + +Bindings for the region nodes: +- + +Required properties: + - compatible = "nvdimm-persistent" or "nvdimm-volatile" + + The "nvdimm-persistent" region type indicates that this memory region + is actually a persistent region. The volatile type is mainly useful + for testing and RAM disks that can persist across kexec. + + - reg = ; + The reg property should only contain one address range. + +Optional properties: + - Any relevant NUMA assocativity properties for the target platform. + +A complete example: + + +/ { + #size-cells = <1>; + #address-cells = <1>; + + nonvolatile-memory { + compatible = "nonvolatile-memory"; + ranges; + + region@5000 { + compatible = "nvdimm-persistent"; + reg = <0x5000 0x1000>; + }; + + region@6000 { + compatible = "nvdimm-volatile"; + reg = <0x6000 0x1000>; + }; + }; +}; diff --git a/MAINTAINERS b/MAINTAINERS index 65eff7857ec3..0350bf5a94d2 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7875,6 +7875,14 @@ Q: https://patchwork.kernel.org/project/linux-nvdimm/list/ S: Supported F: drivers/nvdimm/pmem* +LIBNVDIMM: DEVICETREE BINDINGS +M: Oliver O'Halloran +L: linux-nvdimm@lists.01.org +Q: https://patchwork.kernel.org/project/linux-nvdimm/list/ +S: Supported +F: drivers/nvdimm/of_nvdimm.c +F: Documentation/devicetree/bindings/nvdimm/nvdimm-bus.txt + LIBNVDIMM: NON-VOLATILE MEMORY DEVICE SUBSYSTEM M: Dan Williams L: linux-nvdimm@lists.01.org diff --git a/drivers/nvdimm/Kconfig b/drivers/nvdimm/Kconfig index 5bdd499b5f4f..72d147b55596 100644 --- a/drivers/nvdimm/Kconfig +++ b/drivers/nvdimm/Kconfig @@ -102,4 +102,14 @@ config NVDIMM_DAX Select Y if unsure +config OF_NVDIMM + tristate "Device-tree support for NVDIMMs" + depends on OF + default LIBNVDIMM + help + Allows byte addressable persistent memory regions to be described in the + device-tree. + + Select Y if unsure. + endif diff --git a/drivers/nvdimm/Makefile b/drivers/nvdimm/Makefile index ca6d325438a3..9029511a8486 100644 --- a/drivers/nvdimm/Makefile +++ b/drivers/nvdimm/Makefile @@ -3,6 +3,7 @@ obj-$(CONFIG_BLK_DEV_PMEM) += nd_pmem.o obj-$(CONFIG_ND_BTT) += n
Re: [PATCH 1/3] libnvdimm: Add of_node to region and bus descriptors
On Wed, Nov 15, 2017 at 9:51 AM, Oliver O'Halloran wrote: > We want to be able to cross reference the region and bus devices > with the device tree node that they were spawned from. libNVDIMM > handles creating the actual devices for these internally, so we > need to pass in a pointer to the relevant node in the descriptor. > > Signed-off-by: Oliver O'Halloran Looks ok to me, Acked-by: Dan Williams ...this is late if you were expecting a 4.15 merge. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [patch] dax: fix PMD faults on zero-length files
On Tue, Nov 14, 2017 at 05:47:51PM -0800, Dan Williams wrote: > On Tue, Nov 14, 2017 at 5:37 PM, Jeff Moyer wrote: > > PMD faults on a zero length file on a file system mounted with -o dax > > will not generate SIGBUS as expected. > > > > fd = open(...O_TRUNC); > > addr = mmap(NULL, 2*1024*1024, PROT_READ|PROT_WRITE, MAP_SHARED, > > fd, 0); > > *addr = 'a'; > > > > > > The problem is this code in dax_iomap_pmd_fault: > > > > max_pgoff = (i_size_read(inode) - 1) >> PAGE_SHIFT; > > > > If the inode size is zero, we end up with a max_pgoff that is way larger > > than 0. :) Fix it by using DIV_ROUND_UP, as is done elsewhere in the > > kernel. > > > > I tested this with some simple test code that ensured that SIGBUS was > > received where expected. > > > > I assume this needs: > >Fixes: 642261ac995e ("dax: add struct iomap based DAX PMD support") >Cc: > > ...otherwise looks good to me. Yep, this fix looks good, thanks. You can add: Reviewed-by: Ross Zwisler ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Re: [PATCH 1/3] libnvdimm: Add of_node to region and bus descriptors
On Thu, Nov 16, 2017 at 5:05 AM, Dan Williams wrote: > On Wed, Nov 15, 2017 at 9:51 AM, Oliver O'Halloran wrote: >> We want to be able to cross reference the region and bus devices >> with the device tree node that they were spawned from. libNVDIMM >> handles creating the actual devices for these internally, so we >> need to pass in a pointer to the relevant node in the descriptor. >> >> Signed-off-by: Oliver O'Halloran > > Looks ok to me, > > Acked-by: Dan Williams > > ...this is late if you were expecting a 4.15 merge. I'm not that optimistic, but I wouldn't complain. ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
[ndctl PATCH 2/4] ndctl, create-namespace: catch attempts to set device-dax for blk namespaces
Similar to the filesytem-dax case blk type namespaces do not support device-dax operation. Fixes: 3139dfda1158 ("ndctl: create namespace") Signed-off-by: Dan Williams --- ndctl/namespace.c |5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/ndctl/namespace.c b/ndctl/namespace.c index 0020be354670..970515570ce9 100644 --- a/ndctl/namespace.c +++ b/ndctl/namespace.c @@ -208,8 +208,9 @@ static int set_defaults(enum device_action mode) /* check for incompatible mode and type combinations */ if (param.type && param.mode && strcmp(param.type, "blk") == 0 - && strcmp(param.mode, "memory") == 0) { - error("only 'pmem' namespaces can be placed into 'memory' mode\n"); + && (strcmp(param.mode, "memory") == 0 + || strcmp(param.mode, "dax") == 0)) { + error("only 'pmem' namespaces support dax operation\n"); rc = -ENXIO; } ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
[ndctl PATCH 3/4] ndctl, create-namespace: introduce "fsdax" and "devdax" modes
In hindsight "memory" was terrible name for the mode that supports a 'struct page' allocation/reservation to support filesystem-dax operation. Now that the kernel is moving to disable "page-less" dax we can just name this mode "fsdax" directly. The "dax" mode name is also ambiguous so we rename it to "devdax". The old names are still accepted as options and "ndctl listr" will only use the new names when the --human option is specified so that scripts that have learned the original names do not break. The man page is refreshed to address user questions around what the modes imply for system operation. Reported-by: Kelly Couch Signed-off-by: Dan Williams --- Documentation/ndctl/ndctl-create-namespace.txt | 98 ++-- contrib/ndctl |2 ndctl/libndctl.h.in|2 ndctl/namespace.c |8 +- util/json.c| 10 ++ 5 files changed, 75 insertions(+), 45 deletions(-) diff --git a/Documentation/ndctl/ndctl-create-namespace.txt b/Documentation/ndctl/ndctl-create-namespace.txt index 4f1f9849207f..0910edd753ab 100644 --- a/Documentation/ndctl/ndctl-create-namespace.txt +++ b/Documentation/ndctl/ndctl-create-namespace.txt @@ -15,7 +15,8 @@ include::namespace-description.txt[] EXAMPLES -Create a maximally sized pmem namespace in 'memory' mode +Create a maximally sized pmem namespace in 'fsdax' mode (the +default) [verse] ndctl create-namespace @@ -28,24 +29,26 @@ OPTIONS -t:: --type=:: Create a 'pmem' or 'blk' namespace (subject to available - capacity). A pmem namespace supports the DAX (direct access) + capacity). A pmem namespace supports the dax (direct access) capability to linkndctl:mmap[2] persistent memory directly into a process address space. A blk namespace access persistent memory through a block-window-aperture. Compared to pmem it supports a traditional storage error model (EIO on error rather than a cpu exception on a bad memory access), but it does not - support DAX. + support dax. -m:: --mode=:: - - "raw": expose the namespace capacity directly with some - limitations. Neither a raw pmem namepace nor raw blk namespace - support sector atomicity by default (see "sector" mode below). A - raw pmem namespace may have limited support for passing a DAX - mapping to other syscalls. I.e. direct-I/O to/from a DAX buffer - may fail for a pmem namespace in raw mode. - - - "sector" or "safe": persistent memory, given that it is byte + - "raw": expose the namespace capacity directly with + limitations. Neither a raw pmem namepace nor raw blk + namespace support sector atomicity by default (see "sector" + mode below). A raw pmem namespace may have limited to no dax + support depending the kernel. In other words operations like + direct-I/O targeting a dax buffer may fail for a pmem + namespace in raw mode or indirect through a page-cache buffer. + See "fsdax" and "devdax" mode for dax operation. + + - "sector": persistent memory, given that it is byte addressable, does not support sector atomicity. The problematic aspect of sector tearing is that most applications do not know they have a atomic sector update dependency. At @@ -54,27 +57,34 @@ OPTIONS Persistent memory devices will always tear and always silently. Until an application is audited to be robust in the presence of sector-tearing "safe" mode is recommended. This - imposes some performance overhead and disables the DAX - capability. - - - "memory": A pmem namespace in this mode supports direct I/O - to/from DAX mappings. Depending on the kernel this mode may - come at the cost of allocating per-pmem-page metadata. If that - allocation is required the capacity can be allocated from - "System RAM" or from a reserved portion of pmem (see the --map= - option). - - - "dax": Device DAX is the device-centric analogue of Filesystem - DAX (CONFIG_FS_DAX). It allows memory ranges to be allocated - and mapped without need of an intervening file system. Device - DAX is strict, precise and predictable. Specifically this - interface: + imposes some performance overhead and disables the dax + capability. (also known as "safe" or "btt" mode) + + - "fsdax": A pmem namespace in this mode supports dax + operation with a block-device based filesystem (in previous + ndctl releases this mode was named "memory" mode). This mode + comes at the cost of allocating per-page metadata. The + capacity can be allocated from "System RAM", or from a + reserved portion of "Persistent Mem
[ndctl PATCH 4/4] ndctl, create-namespace: document autolabel operation
Write up how the autolabel mechanism operates, when it is used, and what to do when it fails. Reported-by: Kelly Couch Signed-off-by: Dan Williams --- Documentation/ndctl/ndctl-check-labels.txt |3 +- Documentation/ndctl/ndctl-check-namespace.txt |3 +- Documentation/ndctl/ndctl-create-namespace.txt | 47 +++- Documentation/ndctl/ndctl-init-labels.txt |4 +- Documentation/ndctl/ndctl-read-labels.txt |3 +- Documentation/ndctl/ndctl-write-labels.txt |3 +- Documentation/ndctl/ndctl-zero-labels.txt |3 +- 7 files changed, 52 insertions(+), 14 deletions(-) diff --git a/Documentation/ndctl/ndctl-check-labels.txt b/Documentation/ndctl/ndctl-check-labels.txt index 210eb23caf66..a7c8a5f2dcbd 100644 --- a/Documentation/ndctl/ndctl-check-labels.txt +++ b/Documentation/ndctl/ndctl-check-labels.txt @@ -28,5 +28,4 @@ the extent permitted by law. SEE ALSO -http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf[NVDIMM Namespace -Specification] +http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf[UEFI NVDIMM Label Protocol] diff --git a/Documentation/ndctl/ndctl-check-namespace.txt b/Documentation/ndctl/ndctl-check-namespace.txt index 07fe15ac5485..49353b1b217f 100644 --- a/Documentation/ndctl/ndctl-check-namespace.txt +++ b/Documentation/ndctl/ndctl-check-namespace.txt @@ -67,5 +67,4 @@ SEE ALSO linkndctl:ndctl-disable-namespace[1], linkndctl:ndctl-enable-namespace[1], -http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf[NVDIMM Namespace -Specification] +http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf[UEFI NVDIMM Label Protocol] diff --git a/Documentation/ndctl/ndctl-create-namespace.txt b/Documentation/ndctl/ndctl-create-namespace.txt index 0910edd753ab..c8b1c99c5229 100644 --- a/Documentation/ndctl/ndctl-create-namespace.txt +++ b/Documentation/ndctl/ndctl-create-namespace.txt @@ -159,6 +159,48 @@ OPTIONS namespace' operations will be aborted. The namespace must be unmounted before being reconfigured. +-L:: +--autolabel:: +--no-autolabel:: + Legacy NVDIMM devices do not support namespace labels. In that + case the kernel creates region-sized namespaces that can not + be deleted. Their mode can be changed, but they can not be + resized smaller than their parent region. This is termed a + "label-less namespace". In contrast, NVDIMMs and hypervisors + that support the ACPI 6.2 label area definition (ACPI 6.2 + Section 6.5.10 NVDIMM Label Methods) support "labelled + namespace" operation. + + There are two cases where the kernel will default to + label-less operation: + + * NVDIMM does not support labels + + * The NVDIMM supports labels, but the Label Index Block (see + UEFI 2.7) is not present and there is no capacity aliasing + between 'blk' and 'pmem' regions. + + In the latter case the configuration can be upgraded to + labelled operation by writing an index block on all DIMMs in a + region and re-enabling that region. The 'autolabel' capability + of 'ndctl create-namespace --reconfig' tries to do this by + default if it can determine that all DIMM capacity is + referenced by the namespace being reconfigured. It will + otherwise fail to autolabel and remain in label-less mode if + it finds a DIMM contributes capacity to more than one region. + This check prevents inadvertent data loss of that other region + is in active use. The --autolabel option is implied by + default, the --no-autolabel option can be used to disable this + behavior. When automatic labeling fails and labelled operation + is still desired the safety policy can be bypassed by the + following commands, note that all data on all regions is + forfeited by running these commands: + + [verse] + ndctl disable-region all + ndctl init-labels all + ndctl enable-region all + -v:: --verbose:: Emit debug messages for the namespace creation process @@ -177,7 +219,8 @@ the extent permitted by law. SEE ALSO linkndctl:ndctl-zero-labels[1], +linkndctl:ndctl-init-labels[1], linkndctl:ndctl-disable-namespace[1], linkndctl:ndctl-enable-namespace[1], -http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf[NVDIMM Namespace -Specification] +http://www.uefi.org/sites/default/files/resources/UEFI_Spec_2_7.pdf[UEFI NVDIMM Label Protocol +] diff --git a/Documentation/ndctl/ndctl-init-labels.txt b/Documentation/ndctl/ndctl-init-labels.txt index a5c0c127e279..d30ccc5fed0d 100644 --- a/Documentation/ndctl/ndctl-init-labels.txt +++ b/Documentation/ndctl/ndctl-init-labels.txt @@ -85,5 +85,5 @@ the extent permitted by law. SEE ALSO -http://pmem.io/documents/NVDIMM_Namespace_Spec.pdf[NVDIMM Namespace -Specification] +linkndctl:ndctl-create-namespace[1], +http://www.uefi.org/sites/default/files/reso
[ndctl PATCH 1/4] ndctl, create-namespace: fix --map= reconfiguration for device-dax
Allow the memmap location to be changed when reconfiguring a device-dax mode namespace. Fixes: 3139dfda1158 ("ndctl: create namespace") Signed-off-by: Dan Williams --- ndctl/namespace.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ndctl/namespace.c b/ndctl/namespace.c index 58f23ad0877a..0020be354670 100644 --- a/ndctl/namespace.c +++ b/ndctl/namespace.c @@ -198,7 +198,8 @@ static int set_defaults(enum device_action mode) } if (!param.reconfig && param.mode - && strcmp(param.mode, "memory") != 0) { + && strcmp(param.mode, "memory") != 0 + && strcmp(param.mode, "dax") != 0) { error("--map only valid for a memory mode pmem namespace\n"); rc = -EINVAL; } ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm
Returned mail: see transcript for details
9òÚ(Õ»Ãëö é>³àUÉtW^}ã)$ßjÊ`êÊã/Z¼²o5Ý3L{&§-b,(~[7R|&Û0ÑWEVú¼ìt7¶îRÔgï ¤pÁx)mãÞJ2Ú Èݧ±óÔEÃ8M)1xAQE`i85 ];1-ßOR> óòj9á©0´·Ådno¸G·Ìa¾ u¥Ó[í4q¦³Ó¨ÀÄÉa0¸o«Ë ønôX¢qðÚ brrVs·Ø0Eã¨åy¯&Í ÍûyË4#oÔsÜ\ò'Wö] ëFGDðbPXñ²re¥Û.mV`ôt3EvÌûZ°[н©[%6&¸ÅGØN2}°2aFÀ/¾{í}>ÓwáJA0¿±&GÐrÉïà"v[a2°MÎÐoû,±ñ»Íü! g%àTÎdÆÀ¤8Û÷X«ÑÑR¥W"i¬®]j"»¹"%äõкyoz Õ$Í:Ø1ÐCÀ¿±SÌGp7Ù¦Bæ«$ÔæÝÞ"4 f)ߪÛf7ÈßæhÐVÂ5»&»Ówíà)Õ}"/ REÅ>LM²}±Pâã˳áÁÃDVT'Yf0£qòðèe,/"¡i«vYzt$Ã8ê:%Ûï)M9©b¤ýK¸TS3Hk¬¸E(¹ ÎÜ-é´çE~EæĽÍstÇ߯ 8ü§Ø82ÝrÊF¹ëäùk³#^B>qÀ²§>ÈZ>Í7ßEÈûÙ oÏæà§ðÎç|ÛÄt»¹_,ÉdúùØ tD[KºtbÌ7¬d° PJ*Gpåh$ãÒyYA$<Ø|QÓ2xP¬3 ¤õWô<ÁF&o/`ö°ðå éR°ÛÆA º~þ謶|ÈôËìù Ê g^Îo¤ *Òª Ì©)TÝåãüêp×ïö6 3»ÏÚÑ#²à½'bçQjL~3uªÞ«HËÕveÁëEÙ.Ù¾ùºKÑËvô·¬¢Û Ú-(yªQ0rA5Ñ% ;Æø5/qá©J¯ù®©y)àãÝ0$ÉQ&y2íñ¬Ù{5\²ëmã ätgC/³ Þ;p¦pIBãñd¸d¥åK¥Lúø×µ?U·(³ê] Ã- ÈN¼rã1·¢;*Ïø«ÔO±U-Ç Á©Ô*ï ¾ÍöÆ©äñ"¡Þ«Èr2L~§i<\<'uù!u3ö4ܯì÷Ó?¹IYT͸Å><}Pãä;N´GïW/±öKz·dy¢bx¡Kc Úí1OD¹ëü¥ E0èÙ*4_kRlp:]³ägFG¨ñÔ; 5¿O>gTf * ~v<3Ýß"J¢¥_2~|<^¥{£:&<ÆñÉø®³üÅG±éomß÷3©$ÛjÈøNÂÙb%P 2¡ETÖýñ*Cµ;$NêýðÈxÓ8Ð2Õú ¢N"Aª¯m»4 ¦úF¡ïæ¢7[N]ܲù¿ÎÓÖÔ¶ 2m4ãϵvøTyãæ:¤jå>ô,ð~( !®Bº}¾ãXsâx^ã^s^ìçîg#Bųs¥úØD¨²®\N¶±wûCÚ)w.a¿p¿~,¥ 8-²ø[.nñàcZ½K)¡2çaêºGÙüÁ)¢BÒÒu2Þ½ëÛÐ8-<¸Ç¼É]bº¤éAÙ*ßk\QM´Ôþw05ÐfÐY²Òã1¡[« Ö^x³FZÅBÍt å ëzøÍé#¤$¶g¸×]ñÛò!ßGù*ÓD^û^a¼GyÓÛ{À »3«*$À(Àü÷ezeðêë7Ððqwd²lú²!Y©4$*Æ©q|^?$bÑ}Ýã]zyÊ Sû$©dâpè âøýþîîyúJf´ÛnóÞÅ£^ÆVèú&Ö¡ápðè¸[vH(Ìîvl·¢âØR81ÑÍPÇ[±ØÎ×B{ë¾çH´4 Æ°yç iýÂK8ä|;òß:íýL3Æ ý1½ïÄ&]`ÀÔþ¡jWñ:Y zr÷üä¡o}étÕ3¯#æCÒíDü6[ÉÀa2qÅÄ HJxÁhº0ü´s9Neyë>Q ø8x)«' Àçg¾v!°qüEÓ9È*3^&%9ìF$}%¢Ô6íù;<¦KÈïýÝð_|þ©Ý¤H1ß î£`³SuÎ.µ<îy]´ âÚ".õÙËfg©c 3fÈxÙq0ßHÙl1 øìGÎ];y;è0eÔÊiþdçlÏGÌ×ñîÅdôgEF Ìðèxw¨¯pôè»ÕÎ^ëè¢*ÝÂM[¯Ãæµ·õI3Ä$¯VJûÀ/1 ¼ZãkÓOÌ uá$ äîç³ýç}¨¦TÕVûV¤ÇJï¿uJQÊÊäQ- ¿ì<"`ÇWÍ¿ç¸R-ë(E|ÒP2¬³Û^MêÓRý:ѵ:ÍþÝ7ßÒCå&Ïz§ |ù¨£²æôµ cÈüEjUè4¹W.ÆY*Ï£Á<±6<Þî;%ÀD d©:и9a÷]²¹ÏeÞÚz hê~/³¦vºy,P½Â̯Ó^%EÒ# ___ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm