|
Back
Midas
Rome
Roody
Rootana
|
Midas DAQ System |
Not logged in |
|
|
31 Mar 2022, Stefan Ritt, Suggestion, Maximum ODB size
|
04 Apr 2022, Konstantin Olchanski, Suggestion, Maximum ODB size
|
27 Apr 2023, Marius Koeppel, Suggestion, Maximum ODB size
|
27 Apr 2023, Konstantin Olchanski, Suggestion, Maximum ODB size
|
27 Apr 2023, Marius Koeppel, Suggestion, Maximum ODB size
|
27 Apr 2023, Konstantin Olchanski, Suggestion, Maximum ODB size
|
27 Apr 2023, Konstantin Olchanski, Suggestion, Maximum ODB size
|
28 Apr 2023, Marius Koeppel, Suggestion, Maximum ODB size
|
28 Apr 2023, Stefan Ritt, Suggestion, Maximum ODB size
|
28 Apr 2023, Marius Koeppel, Suggestion, Maximum ODB size
|
28 Apr 2023, Konstantin Olchanski, Suggestion, Maximum ODB size
|
27 Apr 2023, Stefan Ritt, Suggestion, Maximum ODB size
|
28 Apr 2023, Konstantin Olchanski, Suggestion, Maximum ODB size
|
09 Jun 2023, Konstantin Olchanski, Suggestion, Maximum ODB size
|
12 Jun 2023, Stefan Ritt, Suggestion, Maximum ODB size
|
12 Jun 2023, Konstantin Olchanski, Suggestion, Maximum ODB size
|
13 Jun 2023, Stefan Ritt, Suggestion, Maximum ODB size
|
13 Jun 2023, Marius Koeppel, Suggestion, Maximum ODB size
|
13 Jun 2023, Konstantin Olchanski, Suggestion, Maximum ODB size
|
13 Jun 2023, Konstantin Olchanski, Suggestion, Maximum ODB size
|
13 Jun 2023, Stefan Ritt, Suggestion, Maximum ODB size
|
13 Jun 2023, Konstantin Olchanski, Suggestion, Maximum ODB size
|
13 Jun 2023, Stefan Ritt, Suggestion, Maximum ODB size
|
15 Jun 2023, Konstantin Olchanski, Suggestion, Maximum ODB size
|
28 Jul 2023, Stefan Ritt, Suggestion, Maximum ODB size
|
09 Aug 2023, Konstantin Olchanski, Suggestion, Maximum ODB size
|
|
Message ID: 2527
Entry time: 12 Jun 2023
In reply to: 2525
Reply to this: 2528
|
Author: |
Stefan Ritt |
Topic: |
Suggestion |
Subject: |
Maximum ODB size |
|
|
> correction: ODB shared memory is saved to .ODB.SHM each time a client stops, this is db_close_database().
The original design of the midas shared memory (back in the 1990's) was that the ODB shared memory file gets
only saved into the .ODB.SHM when the *last* client exits. This ensures to keep the ODB persistent when the
shared memory gets deleted. I vaguely remember I put something in like:
db_close_database()
...
destroy_flag = (pheader->num_clients == 0);
if (destroy_flag)
ss_shm_flush(pheader->name, pdb->shm_adr, pdb->shm_size, pdb->shm_handle);
...
Now I see that the "if (destory_flag)" is missing. Not sure if it was removed once, or if it actually never
was there. But I see no point in flushing the ODB when a client ends. We need the flushing only before the
shared memory gets deleted. We we have to ensure that the share memory and the binary dump file stay in sync
(like if all midas clients die at the same time), we could add some code to flush the ODB like once per minute,
but not attach it to db_close_database(). I know several experiments using "odbedit -c xxx" in vast quantities,
so all these experiments would then benefit.
Note: Mu3e at PSI also uses 100 MB ODB, and they really need it.
Thoughts and opinions?
Best,
Stefan |