Details
-
Sub-Task
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
None
-
None
-
None
-
2026-8, 2026-9, 2026-10, 2026-11, 2026-12
Description
Change the way of working with shared memory as follows:
- split the shared segment into a fixed-size metadata area and a data area
- in the metadata area, store the key of the current data area
- when making changes to the data area, instead of changing in place, the writer should:
- allocate a new data area
- copy the information from the current data area
- make all necessary changes in the new area
- atomically write the key of the new data area to the metadata
Pros:
- at any given time, there is a consistent state by design
- there is no need for complex synchronization of readers and writers, a pointer to the data area can be stored in the normal address space of the process
- from the point above, it follows that no reader should wait for the completion of data changes
- a writer crash at any time will not cause data corruption, the key always points to completely correct data
Cons:
- it is necessary to think over the mechanism of deleting outdated segments
- similarly for new segments that were not "committed" as current due to a writer crash
- it is possible to worsen the performance of writing due to the need to copy data (it seems that this is not significant, but it should be measured)
Attachments
Issue Links
- includes
-
MCOL-6527 Extent map corrupted from 1 primproc crash - single point of failure
-
- Closed
-
- is duplicated by
-
MCOL-6527 Extent map corrupted from 1 primproc crash - single point of failure
-
- Closed
-
- relates to
-
MCOL-6672 load_brm silently drops journal records when a root process created BRM shared memory on the node first
-
- Open
-
-
MCOL-6682 DBRM worker segfaults rolling back a VBBM/VSS that was never published
-
- Open
-
-
MCOL-6683 Lone worker restart leaves its node on a stale BRM copy (MCS-2031/MCS-2039)
-
- Open
-