Re: PV save and restore tool sought

[Tim Mooney <mooney@aps.anl.gov>]

Emmanuel Mayssat wrote:
> On Fri, 2007-06-29 at 16:55 +0200, Thomas Birke wrote:
>   
> > The warm-reboot save-and-restore is realized with the IOC-based version 
> > of autosave as it comes with the synApps package.
> >     
>
> I am currently investigating warm reboot.
> As such, I am currently investigating autosave and may move away from
> that feature implementation in the driver.
>
> My questions are: 
> * Is autosave the mainstream tool? i.e. the bumpless utility used by
> most of you? I heard at SLAC, they are using channel watcher.
> http://www.slac.stanford.edu/comp/unix/package/epics/extensions/ChannelWatcher/index.html
> Is there anything else that you recommend I look at?
>
> * What are autosave's and your recommended software's limitations? what
> happens in a case of a ioc crash? can backup files be corrupted? Are
> backups saved in files or database? Are files the most simple and
> reliable architecture? what are the disadvantage/advantages of a
> distributed database? central database?
>   
When an ioc crashes, one of autosave's files can be corrupted, but it 
should not
be possible to have both corrupted by a crash (or a reboot) during a 
file write.
However, if the file server says a file is secure, and it's not actually 
secure (e.g.,
it hasn't actually been written to disk) then autosave can end up with 
both copies
corrupted.  If this is a possibility, one should specify that multiple 
copies of the
save file be written.

I don't know if files are the simplest and most reliable architecture, 
but if they
don't work, lots of other things also don't work.

> * What are the disadvantages/advantages of ioc-based backup utility
> versus others designed as ca-client? 
> I read "The current version of Save/Restore (sr), also known as Bumpless
> Reboot, may be interfering with normal IOC operations due to the large
> number of file writes." How much of a problem is that, really?
>   
One advantage of an IOC-based autosave is that it can easily be made to 
start
automatically whenever the IOC boots up.

A disadvantage of this particular backup utility is that it overwrites 
the entire
save file if any PV in the file has changed.  At one point this was a 
generic
limitation of least-common-denominator IOC software (vxWorks netDrv
did not permit random access to a file).  But now, since autosave 
requires NFS,
it's just an annoying holdover that should be fixed.
> * Is there a SIMPLE way to generate a req/request file on the fly for
> backup? I have "dynamic" ioc, where the names of records may change
> between reboots, or some records may just disappear. Do you have each
> time to reconfigure the backup request file? Although I believe this
> should be required for a general backup utility, why should it for a
> bumpless reboot utility?
>   
The list of PV's to be saved does not automatically configure itself to 
match
PV's actually loaded.  Autosave tolerates missing PV's, but if PV's come and
go, their old values will not automatically be restored when they come back.
> Is it possible to generate a req file at ioc startup that save all the
> "live" records with name's ending with *O or *AO, etc. ( a dbgrep to a
> file can help, but the backup utility needs to reread its config files )
>   
Yes, but autosave doesn't provide much help.  If you have a generic 
request file
for each record type, listing the PV's that should be managed for that 
record type,
you could use autosave's include-file capability to help with the job.
> * What happens if the backup utility is looking for a record that
> doesn't exist? Is backup still ongoing? Does it significantly increase
> the traffic load on the network?
>
>   
Autosave doesn't kill itself if it can't find a PV.  It's just a CA 
client, so its effect
on the network when PV's are not found is the same as any other CA client.
> * Is log-on-change possible for individual output records? I heard this
> is not the forte of autosave, but I may be wrong.
>
>   
Autosave doesn't log anything.  It maintains only the most recent value.
> * What if there are no values previously saved on the particular ioc.
> What is the default value? The one in db file? Is it possible to
> import/copy backup data? 
>
>   
If autosave has no value to restore, it will simply not restore, so the 
value in the
database is used.
> * Although I am mostly interested in bumpless reboot, are there
> utilities that do bumpless reboot in a very similar way they do regular
> backup? I am currently using sddscasr (casr in sdds files ), but am
> reacquainting myself with casr and burt. Should I look at those or are
> they deprecated? Should I look at any other applications?
>
>   
I don't know whether casr and burt are still being maintained.  Any 
client that
can write a file can cause autosave to have that file restored at boot time.
Autosave's save and restore operations are  separately configured, so it can
restore files that it did not save, and save files that it will not restore.
> * etc.
>
>
> --
> Emmanuel
>
>   


--
Tim Mooney (mooney@aps.anl.gov) (630)252-5417
Beamline Controls & Data Acquisition Group (www.aps.anl.gov/aod/bcda)
Advanced Photon Source, Argonne National Lab