On Wed, 2019-08-28 at 13:47 -0700, Scargall, Steve wrote:
> Hi Jeff,
>
> The issue is more of repetition. On an 8-socket system, should a
> user really be expected to type 'ndctl create-namespace' eight times
> vs. running 'ndctl create-namespace --region=all' once? SAP HANA is
> an example app the requires one namespace per region. Scripting is a
> viable solution, but that requires somebody to write the script and do
> all the error checking & handling. Each OEM/ISV/SysAdmin would have
> their own script. Pushing the logic to ndctl seems to be a reasonable
> approach and let the user handle any errors returned by ndctl.
A scripted solution can indeed be really simple - e.g.:
# while read -r region; do ndctl create-namespace --region="$region";
done < <(ndctl list --bus=nfit_test.0 -R | jq -r '.[].dev')
{
"dev":"namespace5.0",
"mode":"fsdax",
"map":"dev",
"size":"62.00 MiB (65.01 MB)",
"uuid":"c8014457-c268-4f22-8eae-6386fbf08ceb",
"sector_size":512,
"align":2097152,
"blockdev":"pmem5"
}
{
"dev":"namespace4.0",
"mode":"fsdax",
"map":"dev",
"size":"30.00 MiB (31.46 MB)",
"uuid":"f9498ef6-cdd6-46c7-95f1-86469546ecb9",
"sector_size":512,
"align":2097152,
"blockdev":"pmem4"
}
>
> The ndctl-man-page implies the 'ndctl create-namespace --region=all'
> feature exists today:
>
> -r, --region=
>
> A regionX device name, or a region id number. The keyword
> all can be specified to carry out the operation on every region in the
> system, optionally filtered by bus id (see --bus= option).
>
This is true, but unfortunately, the implementation has treated create-
namespace as an exception to this since the start, and I agree with Jeff
that changing its behavior now can cause other Hyrum's law-esqe [1]
breakage.
I think however it should be easy to make a compromise, and retain the
legacy behavior of create-namespace, while creating a new create-
namespace-greedy command with the new semantics.
Thoughts on that?
Thanks,
-Vishal
[1]: http://www.hyrumslaw.com/
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm
