| Message ID | 20210831090459.2306727-3-vishal.l.verma@intel.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Policy based reconfiguration for daxctl | expand |
On Tue, Aug 31, 2021 at 2:05 AM Vishal Verma <vishal.l.verma@intel.com> wrote: > > Add a man page update describing how daxctl-reconfigure-device(1) can > be used for persistent reconfiguration of a daxctl device using a > config file. > > Cc: Dan Williams <dan.j.williams@intel.com> > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> > --- > .../daxctl/daxctl-reconfigure-device.txt | 67 +++++++++++++++++++ > 1 file changed, 67 insertions(+) > > diff --git a/Documentation/daxctl/daxctl-reconfigure-device.txt b/Documentation/daxctl/daxctl-reconfigure-device.txt > index f112b3c..1e2d380 100644 > --- a/Documentation/daxctl/daxctl-reconfigure-device.txt > +++ b/Documentation/daxctl/daxctl-reconfigure-device.txt > @@ -162,6 +162,15 @@ include::region-option.txt[] > brought online automatically and immediately with the 'online_movable' > policy. Use this option to disable the automatic onlining behavior. > > +-C:: > +--check-config:: > + Get reconfiguration parameters from the global daxctl config file. > + This is typically used when daxctl-reconfigure-device is called from > + a systemd-udevd device unit file. The reconfiguration proceeds only > + if the UUID of the dax device passed in on the command line matches > + a UUID listed in the auto-online section of the config. See the > + 'PERSISTENT RECONFIGURATION' section for more details. There's going to be other match parameters in the future, so this can probably say something like: "The reconfiguration proceeds only if the match parameters in a 'reconfigure-device' section of the config match dax device specified on the command line" > + > include::movable-options.txt[] > > -f:: > @@ -183,6 +192,64 @@ include::human-option.txt[] > > include::verbose-option.txt[] > > +PERSISTENT RECONFIGURATION > +-------------------------- > + > +The 'mode' of a daxctl device is not persistent across reboots by default. This > +is because the device itself may hold any metadata that hints at what mode it s/may hold any/does not hold/ > +was set to, or is intended to be used in. The default mode for such a device s/in// > +is 'devdax', and on reboot, that is the mode devices appear in by default. s/, that is the mode devices appear in by default// i.e. redundant. > + > +The administrator may desire to configure the system in a way that certain How about: "The administrator may set policy such that certain dax devices are always reconfigured into a target configuration every boot." > +dax devices are always reconfigured into a certain mode every time on boot. > +This is accomplished via a daxctl config file located at [location TBD]. > + > +The config file may have multiple sections influencing different aspects of > +daxctl operation. The section of interest for persistent reconfiguration is > +'auto-online'. The format of this is as follows: > + > +---- > +[auto-online <subsection_name>] > +uuid = <namespace uuid> > +mode = <desired reconfiguration mode> (default: system-ram) > +online = <true|false> (default: true) > +movable = <true|false> (default: true) > +---- > + > +Here is an example of a config snippet for managing three devdax namespaces, > +one is left in devdax mode, the second is changed to system-ram mode with > +default options (online, movable), and the third is set to system-ram mode, > +the memory is onlined, but not movable. > + > +Note that the 'subsection name' can be arbitrary, and is only used to > +identify a specific config section. It does not have to match the 'device > +name' (e.g. 'dax0.0' etc). > + > +---- > +[auto-online dax0] > +uuid = ed93e918-e165-49d8-921d-383d7b9660c5 > +mode = devdax > + > +[auto-online dax1] > +uuid = f36d02ff-1d9f-4fb9-a5b9-8ceb10a00fe3 > +mode = system-ram > + > +[auto-online dax2] > +uuid = f36d02ff-1d9f-4fb9-a5b9-8ceb10a00fe3 > +mode = system-ram > +online = true > +movable = false One of the tasks I envisioned with persistent configurations was recalling resize and create device operations. Not saying that needs to be included now, but I can assume that these reconfiguration steps are performed in order... Hmm, as I ask that I realize it may depend on device arrival. Ok, assuming the devices have all arrived by the time this runs is there a guarantee that these are processed in order? > +---- > + > +The following example can be used to create a devdax mode namespace, and > +simultaneously add the newly created namespace to the config file for > +system-ram conversion. > + > +---- > +ndctl create-namespace --mode=devdax | \ > + jq -r "\"[auto-online $(uuidgen)]\", \"uuid = \(.uuid)\", \"mode = system-ram\"" >> $config_path > +---- > + > include::../copyright.txt[] > > SEE ALSO > -- > 2.31.1 >
On Thu, 2021-09-16 at 15:47 -0700, Dan Williams wrote: > On Tue, Aug 31, 2021 at 2:05 AM Vishal Verma <vishal.l.verma@intel.com> wrote: > > > > Add a man page update describing how daxctl-reconfigure-device(1) can > > be used for persistent reconfiguration of a daxctl device using a > > config file. > > > > Cc: Dan Williams <dan.j.williams@intel.com> > > Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> > > --- > > .../daxctl/daxctl-reconfigure-device.txt | 67 +++++++++++++++++++ > > 1 file changed, 67 insertions(+) > > [snip] (I've made all the other documentation changes suggested). > > > > + > > +[auto-online dax2] > > +uuid = f36d02ff-1d9f-4fb9-a5b9-8ceb10a00fe3 > > +mode = system-ram > > +online = true > > +movable = false > > One of the tasks I envisioned with persistent configurations was > recalling resize and create device operations. Not saying that needs > to be included now, but I can assume that these reconfiguration steps > are performed in order... Hmm, as I ask that I realize it may depend > on device arrival. Ok, assuming the devices have all arrived by the > time this runs is there a guarantee that these are processed in order? Hm, I don't quite follow what you mean by processing in order. The logic here is that there are two 'classes' of config items in this section - 'identification' and 'action' The uuid is the only identification item - it is used to match the right device. The others - 'action' items, dictate what will be done to that device. The order here doesn't (shouldn't?) matter as these just set the param.foo fields in daxctl/device.c, and let do_reconfig() run wild with them, just as if the params were specified on the command line.
diff --git a/Documentation/daxctl/daxctl-reconfigure-device.txt b/Documentation/daxctl/daxctl-reconfigure-device.txt index f112b3c..1e2d380 100644 --- a/Documentation/daxctl/daxctl-reconfigure-device.txt +++ b/Documentation/daxctl/daxctl-reconfigure-device.txt @@ -162,6 +162,15 @@ include::region-option.txt[] brought online automatically and immediately with the 'online_movable' policy. Use this option to disable the automatic onlining behavior. +-C:: +--check-config:: + Get reconfiguration parameters from the global daxctl config file. + This is typically used when daxctl-reconfigure-device is called from + a systemd-udevd device unit file. The reconfiguration proceeds only + if the UUID of the dax device passed in on the command line matches + a UUID listed in the auto-online section of the config. See the + 'PERSISTENT RECONFIGURATION' section for more details. + include::movable-options.txt[] -f:: @@ -183,6 +192,64 @@ include::human-option.txt[] include::verbose-option.txt[] +PERSISTENT RECONFIGURATION +-------------------------- + +The 'mode' of a daxctl device is not persistent across reboots by default. This +is because the device itself may hold any metadata that hints at what mode it +was set to, or is intended to be used in. The default mode for such a device +is 'devdax', and on reboot, that is the mode devices appear in by default. + +The administrator may desire to configure the system in a way that certain +dax devices are always reconfigured into a certain mode every time on boot. +This is accomplished via a daxctl config file located at [location TBD]. + +The config file may have multiple sections influencing different aspects of +daxctl operation. The section of interest for persistent reconfiguration is +'auto-online'. The format of this is as follows: + +---- +[auto-online <subsection_name>] +uuid = <namespace uuid> +mode = <desired reconfiguration mode> (default: system-ram) +online = <true|false> (default: true) +movable = <true|false> (default: true) +---- + +Here is an example of a config snippet for managing three devdax namespaces, +one is left in devdax mode, the second is changed to system-ram mode with +default options (online, movable), and the third is set to system-ram mode, +the memory is onlined, but not movable. + +Note that the 'subsection name' can be arbitrary, and is only used to +identify a specific config section. It does not have to match the 'device +name' (e.g. 'dax0.0' etc). + +---- +[auto-online dax0] +uuid = ed93e918-e165-49d8-921d-383d7b9660c5 +mode = devdax + +[auto-online dax1] +uuid = f36d02ff-1d9f-4fb9-a5b9-8ceb10a00fe3 +mode = system-ram + +[auto-online dax2] +uuid = f36d02ff-1d9f-4fb9-a5b9-8ceb10a00fe3 +mode = system-ram +online = true +movable = false +---- + +The following example can be used to create a devdax mode namespace, and +simultaneously add the newly created namespace to the config file for +system-ram conversion. + +---- +ndctl create-namespace --mode=devdax | \ + jq -r "\"[auto-online $(uuidgen)]\", \"uuid = \(.uuid)\", \"mode = system-ram\"" >> $config_path +---- + include::../copyright.txt[] SEE ALSO
Add a man page update describing how daxctl-reconfigure-device(1) can be used for persistent reconfiguration of a daxctl device using a config file. Cc: Dan Williams <dan.j.williams@intel.com> Signed-off-by: Vishal Verma <vishal.l.verma@intel.com> --- .../daxctl/daxctl-reconfigure-device.txt | 67 +++++++++++++++++++ 1 file changed, 67 insertions(+)