Re: autosave issues

[David Maden <David.Maden@psi.ch>]

Our users also found the 8-file limitation too severe. I increased it to 20 
quite easily.

Some of our users also like to use the autorestore function to initialise 
database entries, without any corresponding autosave function. They 
generate the autosave files using other software. This practice has 
established itself to the extent that their autosave files are even located 
on a read-only file system ... which then resulted in moans about the error 
messages generated by autorestore when it couldn't write its backup files. 
This led to a less trivial modification to allow files to be flagged as 
"restore-only", in which case there is no attempt to write backup files 
during the autorestore phase.

Regarding the question of which pass fields should be restored in, the only 
special case I have come across is that of motor VAL fields. As I 
understand it, if the motor record sees that a VME58 card has a non-zero 
step counter, it will use this value to initialise the motor's VAL field. 
The assumption is that a warm reboot of the IOC has just occurred, and that 
the step counter is therefore valid. This seems to me to be a good 
strategy. However, for motors without encoders, it is standard practice to 
autosaverestore the VAL field so that a motor's position will generally 
survive a power cycle of the IOC. In that case, the autorestore should be 
PASS 0 ONLY. A non-zero step counter in the VME58 card will then take 
precedence over autorestore.

David

Tim Mooney wrote:
> The 8-file limitation is still in the code.  I never thought about having a
> restore file per device.  The limitation would be easy to lift if you 
> didn't
> care about status PV's.  There's a hard-coded structure in dbrestore.c, and
> a macro in save_restore.h.  I think that's all you'd have to change, but 
> I've
> never tried it.
>
> Pass 1 is just after record initialization.  Too late to restore link
> fields, and too late to use the restored value in device support's init,
> but ok for most other things, including arrays and fields whose type is 
> set during record init.
>
> It's probably best to use both passes unless you want to avoid overwriting
> a value the record/device set during its init.  Otherwise you have to
> segregate PV's by field types, because some types can only be restored in
> one of the two passes.
>
> Tim
>
> Mark Rivers wrote:
> > I don't know about the 8 file limitation.  Tim Mooney may know about 
> > that.
> >
> > pass0 is like setting VAL in the db file.  pass1 is not like a caput, 
> > it does
> > not cause the record to process, because it is all still done before 
> > iocInit.
> > It has to do with the timing relative to when links have been 
> > established I
> > think.
> >
> > vxWorks typically has no local disk, and NFS is the preferred file 
> > system.
> > For computer-based IOC you don't need to worry about, you can just 
> > save to a
> > local disk.
> >
> > Mark
> >
> >
> > ________________________________
> >
> > From: Emmanuel Mayssat [mailto:emmanuel_mayssat@lynceantech.com] Sent: 
> > Wed
> > 4/16/2008 7:11 PM To: Mark Rivers Cc: epics Subject: RE: autosave issues
> >
> >
> >
> > Mark,
> >
> > I implemented autosave relatively easily thanks to the documentation. 
> > For the
> > set_passX_restoreFile functions, it says that only 8 files can be 
> > restored at
> > each pass.
> >
> > This is rather an important limitation if I have a restore file per 
> > device
> > (and not 1 per ioc). Is this limitation still applicable?
> >
> > Is doing a restore at pass0 equivalent to setting the VAL fields in 
> > the db
> > file? For pass1, is it equivalent to having several caputs on a 
> > running ioc?
> >
> > Why do they recommend saving vxWorks station over NFS? I assume it is 
> > only
> > because of a storage space limitation. If that is the case, then it is 
> > not
> > applicable for computer-based IOC. Isn't it?
> >
> > Regards,
> >
> > -- E
> >
> >
> >
> > On Tue, 2008-04-15 at 21:22 -0500, Mark Rivers wrote:
> > > The problems are probably less frequent than that.  And a beamline 
> > > might be
> > > 4 IOCs.
> > >
> > > The issues tend to arise during power or network failures when the 
> > > vxWorks
> > > VME IOC is in the middle of saving the file via NFS.
> > >
> > > There are safeguards now in place that make this much less likely.  And
> > > there are backup files created by the autosave system that can be 
> > > recovered
> > > from.
> > >
> > > Mark
> > >
> > >
> > > ________________________________
> > >
> > > From: tech-talk-bounces@aps.anl.gov on behalf of Emmanuel Mayssat 
> > > Sent: Tue
> > > 4/15/2008 8:35 PM To: epics Subject: autosave issues
> > >
> > >
> > >
> > > Hello again,
> > >
> > > I was looking at autosave record/functions. I read that APS is 
> > > experiencing
> > > at least 1 autosave issue per beamline, per year. Can anyone expend on
> > > that?
> > >
> > > I assume that files are being corrupted or such... How could that 
> > > happen?
> > >
> > > -- Emmanuel