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
--
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group
Advanced Photon Source, Argonne National Lab.
- Replies:
- Re: autosave issues David Maden
- References:
- autosave issues Emmanuel Mayssat
- RE: autosave issues Mark Rivers
- RE: autosave issues Emmanuel Mayssat
- RE: autosave issues Mark Rivers
- Navigate by Date:
- Prev:
RE: autosave issues Mark Rivers
- Next:
Re: autosave issues David Maden
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: autosave issues Mark Rivers
- Next:
Re: autosave issues David Maden
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
<2008>
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|