1. Auto Save and Restore Dirk Zimoch, KSTAR Meeting 2009

2. 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

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

4. 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

5. 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

6. Example: <iocboot>/rf1.req # rf plant 1RF1:VOLTAGE:SETRF1:PHASE:SET 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) Dirk Zimoch, KSTAR Meeting 2009

7. Minimal configuration in startup script Example values 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 "/iocBoot/RF1-ioc/" "/autoSR/RF1-ioc/" "RF1-ioc:" "P=RF1-ioc:" "rf1.sav" "rf1.req", 30 Dirk Zimoch, KSTAR Meeting 2009

8. 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

9. 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 atwww.aps.anl.gov/bcda/synApps/autosave/autoSaveRestore_R4-4.html Dirk Zimoch, KSTAR Meeting 2009