EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: autosave issues
From: David Maden <[email protected]>
Cc: epics <[email protected]>
Date: Thu, 17 Apr 2008 10:04:04 +0200
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:[email protected]] 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: [email protected] 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

References:
autosave issues Emmanuel Mayssat
RE: autosave issues Mark Rivers
RE: autosave issues Emmanuel Mayssat
RE: autosave issues Mark Rivers
Re: autosave issues Tim Mooney

Navigate by Date:
Prev: Re: autosave issues Tim Mooney
Next: RE: sequence compilation in multi-device IOC Emmanuel Mayssat
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: autosave issues Tim Mooney
Next: Channel Archiver building problem in Make Install command Tasaddaq Ali Khan
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  <20082009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·