----- Original Message -----
> From: "Emmanuel Mayssat" <[email protected]>
> To: "Kay Kasemir" <[email protected]>
> Cc: "emmanuel mayssat" <[email protected]>, [email protected]
> Sent: Tuesday, April 16, 2013 5:03:12 PM
> Subject: RE: autosave limitation?
>
>
>
>
> > Depending on what version of autosave you are using, you can work
> > without any standalone autosave config files.
> > Instead, you add annotations to your database records:
> >
> > record(type, "$(S):SomeRecord")
> > {
> > info(autosaveFields, "VAL LOW")
> > In your IOC startup file you then add a command that auto-creates
> > the request files from those database annotations:
> >
> > makeAutosaveFileFromDbInfo("autocreated.req", "autosaveFields");
> > create_monitor_set("autocreated.req.req", 5)
> >
>
>
> Again, I want the flexibility to have 1 master IOC with 20 devices to
> be broken in several
> (i.e. let's say I reconfigure the master IOC with 15 devices and 5
> single-device IOCs that actively being developed)
> This should of course be transparent from the EPICS client
> perspective
> (i.e. restored values are the same)
>
>
> [...]
> I understand how to generate the req file (dbgrep * > file.req or
> more complicated as described above)
> But what about restoring the PVs, i.e. what about the sav files?
>
>
> There are 2 solutions:
> 1/ Have one req file per device --> one sav file per device
> 2/ Have one req file per device --> one sav file used for all IOCs
>
>
> But
> 1/ Limits on number of sav files in autosave
> 2/ I anticipate issues as several processes try to write to the same
> file
>
>
> is there a reason why autosave is limited to 8 files?
> Can this limit be raise to say ... 1000?
> Better yet, can this limit be removed?
>
>
> I moved away from autosave some time ago due to that limit.
> Is there anything that has the same functionality as autosave but
> would better fit my development methodology?
>
>
> Regards,
> --
> Emmanuel
There's no real reason autosave is limited to 8 files, other than that I
didn't know anyone wanted more than that. I haven't tested large numbers
of files, but you can edit save_restore.h and change
#define MAXRESTOREFILES 8
to whatever you want. The number of save files is already unlimited (you
can make as many create_monitor_set() calls as you want.)
Yes, the number of restore files could be made unlimited. That's what I
meant to imply when I said that the list of restore file names could be
implemented as a linked list. If someone wants 1000 files, then a linked
list is probably called for. If 30 is enough, then
#define MAXRESTOREFILES 30
seems adequate. All we're doing is allocating an array of pointers.
Tim
--
Tim Mooney ([email protected]) (630)252-5417
Software Services Group (www.aps.anl.gov)
Advanced Photon Source, Argonne National Lab
- Replies:
- RE: autosave limitation? Emmanuel Mayssat
- References:
- RE: autosave limitation? Emmanuel Mayssat
- Navigate by Date:
- Prev:
Re: EPICS UTC Time conversion Eric Norum
- Next:
RE: sscan/ saveData problem with RW permission, and not an NFS issue Vesna Samardzic-Boban
- 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 limitation? Emmanuel Mayssat
- Next:
RE: autosave limitation? Emmanuel Mayssat
- 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
|