Dirk Zimoch, KSTAR Meeting 2009 Auto Save and Restore

Dirk Zimoch, KSTAR Meeting 2009 Auto Save and Restore What is Auto Save and Restore (autoSR)? ■ It allows to save settings over a reboot. ► Settings that cannot be read back from hardware ► Settings that are not connected to any hardware ■ Records (fields) are saved to files whenever they change ■ … and restored after reboot before IOC starts. It is not a replacement for regular machine snapshots! When using autoSR, reboot does no longer heal everything!

Dirk Zimoch, KSTAR Meeting 2009 Auto Save and Restore What to save? ai Hardware with readback ao OUT INP calcout A+B ao INPA INPB OUT ai Hardware without readback ao OUT INP ■ Set values that cannot be restored from hardware ■ Only values that normally change. Don't save fixed parameters. Use field (PINI, "YES") to initialize Driver should initialize record in init_record() field (PINI, "YES") Better not save the CALC field autoSR

Dirk Zimoch, KSTAR Meeting 2009 Auto Save and Restore How it works ■ Auto Save ► One or more "save sets" (lists of records) are watched. ● A channel access monitor is set up for each record. ► On each change, a save set writes a "save file" to disc. ● There is a dead time to prevent too frequent writes. ■ Restore ► During "iocInit" one or more save files are loaded. ► The file can be loaded before (pass 0) or after (pass 1) init_record(). ● Some fields and drivers have different requirement for this. ► The records start with their latest known value.

Dirk Zimoch, KSTAR Meeting 2009 Auto Save and Restore Status and debug records ■ AutoSR writes status of save sets in records. ■ Allows to show status on CA clients (medm, alarm handler). ■ Records are prefixed (e.g. with IOC name) ■ medm screen provided

Dirk Zimoch, KSTAR Meeting 2009 Auto Save and Restore Preparations ■ Create a "request file" for each save set ► Plain list of records or fields to be saved ► Comments with # ► Macros and includes possible ● Useful for similar sets of records on different devices or IOCs. ■ Install request files (e.g. to IOC boot directory) ■ Prepare a writable directory for "save files" ► One directory for each IOC ► Do not write into the IOC boot directory ► NFS mounted or on local disc (not on flash) Example: /rf1.req # rf plant 1 RF1:VOLTAGE:SET RF1:PHASE:SET

Dirk Zimoch, KSTAR Meeting 2009 Auto Save and Restore Minimal configuration in startup script set_requestfile_path "directory" set_savefile_path "writable_directory" save_restoreSet_status_prefix "iocname:" dbLoadRecords "save_restoreStatus.db","P=iocname:" autoSRhookInit... set_pass0_restoreFile "saveset0.sav" set_pass1_restoreFile "saveset1.sav" iocInit create_monitor_set "saveset0.req", dead_seconds create_monitor_set "saveset1.req", dead_seconds "rf1.req", 30 "/iocBoot/RF1-ioc/" "/autoSR/RF1-ioc/" "RF1-ioc:" "P=RF1-ioc:" "rf1.sav" Example values

Dirk Zimoch, KSTAR Meeting 2009 Auto Save and Restore Which values to restore in which pass? ■ Pass0: before device support and driver initialize record ■ Pass1: before record processes the first time ■ Driver needs value during initialization → use pass0 ■ Driver overwrites value during initialization → use pass1 ■ Link fields (e.g. INPA) → must use pass0 ■ Arrays → must use pass1 ■ Malloc'ed fields (e.g. genSub.A) → must use pass1 ■ Motor positions → use pass0

Dirk Zimoch, KSTAR Meeting 2009 Auto Save and Restore Advanced features (not discussed here) ■ Sequential and dated backups ■ Macro substitution ■ Debug messages ■ Manual save or restore ■ Manipulating save files ■ Automatic NFS mount / remount (vxWorks only)  See the complete manual at