On Tue, Jan 13, 2026 at 12:33 AM Ira Weiny <[email protected]> wrote: > > Michał Cłapiński wrote: > > On Wed, Dec 17, 2025 at 4:14 AM <[email protected]> wrote: > > > > > > Michał Cłapiński wrote: > > > [..] > > > > > Sure, then make it 1280K of label space. There's no practical limit in > > > > > the implementation. > > > > > > > > Hi Dan, > > > > I just had the time to try this out. So I modified the code to > > > > increase the label space to 2M and I was able to create the > > > > namespaces. It put the metadata in volatile memory. > > > > > > > > But the infoblocks are still within the namespaces, right? If I try to > > > > create a 3G namespace with alignment set to 1G, its actual usable size > > > > is 2G. So I can't divide the whole pmem into 1G devices with 1G > > > > alignment. > > > > > > Ugh, yes, I failed to predict that outcome. > > > > > > > If I modify the code to remove the infoblocks, the namespace mode > > > > won't be persistent, right? In my solution I get that information from > > > > the kernel command line, so I don't need the infoblocks. > > > > > > So, I dislike the command line option ABI expansion proposal enough to > > > invest some time to find an alternative. One observation is that the > > > label is able to indicate the namespace mode independent of an > > > info-block. The info-block is only really needed when deciding whether > > > and how much space to reserve to allocate 'struct page' metadata. > > > > > > -- 8< -- > > > From 4f44cbb6e3bd4cac9481bdd4caf28975a4f1e471 Mon Sep 17 00:00:00 2001 > > > From: Dan Williams <[email protected]> > > > Date: Mon, 15 Dec 2025 17:10:04 -0800 > > > Subject: [PATCH] nvdimm: Allow fsdax and devdax namespace modes without > > > info-blocks > > > MIME-Version: 1.0 > > > Content-Type: text/plain; charset=UTF-8 > > > Content-Transfer-Encoding: 8bit > > > > > > Michał reports that the new ramdax facility does not meet his needs which > > > is to carve large reservations of memory into multiple 1GB aligned > > > namespaces/volumes. While ramdax solves the problem of in-memory > > > description of the volume layout, the nvdimm "infoblocks" eat capacity and > > > destroy alignment properties. > > > > > > The infoblock serves 2 purposes, it indicates whether the namespace should > > > operate in fsdax or devdax mode, Michał needs this, and it optionally > > > reserves namespace capacity for storing 'struct page' metadata, Michał > > > does > > > not need this. It turns out the mode information is already recorded in > > > the > > > namespace label, and if no reservation is needed for 'struct page' > > > metadata > > > then infoblock settings can just be hard coded. > > > > > > Introduce a new ND_REGION_VIRT_INFOBLOCK flag for ramdax to indicate that > > > all infoblocks be synthesized and not consume any capacity from the > > > namespace. > > > > > > With that ramdax can create a full sized namespace: > > > > > > $ ndctl create-namespace -r region0 -s 1G -a 1G -M mem > > > { > > > "dev":"namespace0.0", > > > "mode":"fsdax", > > > "map":"mem", > > > "size":"1024.00 MiB (1073.74 MB)", > > > "uuid":"c48c4991-86af-4de1-8c7c-8919358df1f9", > > > "sector_size":512, > > > "align":1073741824, > > > "blockdev":"pmem0" > > > } > > > > Thank you for working on this. > > > > I tried it an indeed it works with fsdax. It doesn't seem to work with > > devdax though. > > > > $ ndctl create-namespace -v -r region1 -m devdax -a 1G -M mem -s 1G > > libndctl: ndctl_dax_enable: dax1.0: failed to enable > > Error: namespace1.1: failed to enable > > > > failed to create namespace: No such device or address > > > > $ dmesg | grep dax > > [...] > > [ 29.504763] dax_pmem dax1.0: could not reserve metadata > > [ 29.504766] dax_pmem dax1.0: probe with driver dax_pmem failed with > > error -16 > > [ 29.506553] probe of dax1.0 returned 16 after 1815 usecs > > [...] > > > > I think the dax_pmem driver needs to be modified too. > > Michał > > Did yall have a suggestion on how? I lost track of this thread over the > holidays and so I'm not sure where this stands. > > Ira
I think Dan's change needs to skip devm_request_mem_region if offset == 0 in __dax_pmem_probe in drivers/dax/pmem.c.
