Experimental Physics and
Industrial Control System

"Elder Matias" <[email protected]> · Tue, 31 Jul 2007 15:07:42 -0600

I think you are hard pressed to say there is a main-stream solution.  It
looks like there are quite a few labs using autosave while other have
different requirements and therefore different tools.

At the CLS we use a locally developed auto-save.  We have diskless RTEMS
machines embedded in a lot of our equipment.  As well our accelerator
operations group wanting the ability to "undo" changes.

In our case all the data and auto-save restore software runs on a
Scientific Linux server with RAID or a SAN.

I think you are just going to have to determine what system best meets
your requirements.

Elder

----------------
To: Thomas Birke <[email protected]> 
Subject: Re: PV save and restore tool sought 
From: Emmanuel Mayssat <[email protected]> 
Date: Tue, 31 Jul 2007 12:00:13 -0700 
Cc: [email protected] 
In-reply-to: <[email protected]> 
References:
<8CF98BE8D19EA84BA2271BE19BE8F83402976744@exch-mail2.win.slac.stanford.e
du> <[email protected]> 

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/ChannelW
atcher/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?

* 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?

* 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?
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 )

* 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?

* Is log-on-change possible for individual output records? I heard this
is not the forte of autosave, but I may be wrong.

* 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? 

* 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?

* etc.

--
Emmanuel

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System