On Tue, Aug 31, 2021 at 2:05 AM Vishal Verma <[email protected]> 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 <[email protected]> > Signed-off-by: Vishal Verma <[email protected]> > --- > .../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 >
