You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A few thoughts on how to implement GC when there are still other processes running:
As discussed previously, we could move blocks at the end of the file to fill holes in the middle. Let' call it relocation. For the blocks that are organized as linked lists (e.g. LogEntryBlock), we could use an RCU to atomically relocate the block: copy it to the hole and CAS to update the pointer pointing to it.
To relocate DataBlock, we must scan through the log (and clean up dead log entries too), since the log will contain pointer points to DataBlock.
In MetaBlock, we maintain a gc_clock, which is a logical clock (or version number, if this is a better term); every time a GC completes, increase gc_clock by one. In the current block allocation, every process will always try to allocate from the recent bitmap it has successfully allocated; if fails, then try to allocate from the next bitmap, so bitmaps are searched in increasing order. When a process fails to allocate blocks from the last bitmap, it then tries to extend the bitmap. Now that we gc_clock, the process could compare it to the last gc_clock it has seen. If it is mismatched, it means a new GC happened so instead of extending the file, it tries to rescan all the bitmap from the head.
The text was updated successfully, but these errors were encountered:
A few thoughts on how to implement GC when there are still other processes running:
LogEntryBlock
), we could use an RCU to atomically relocate the block: copy it to the hole and CAS to update the pointer pointing to it.DataBlock
, we must scan through the log (and clean up dead log entries too), since the log will contain pointer points toDataBlock
.MetaBlock
, we maintain agc_clock
, which is a logical clock (or version number, if this is a better term); every time a GC completes, increasegc_clock
by one. In the current block allocation, every process will always try to allocate from the recent bitmap it has successfully allocated; if fails, then try to allocate from the next bitmap, so bitmaps are searched in increasing order. When a process fails to allocate blocks from the last bitmap, it then tries to extend the bitmap. Now that wegc_clock
, the process could compare it to the lastgc_clock
it has seen. If it is mismatched, it means a new GC happened so instead of extending the file, it tries to rescan all the bitmap from the head.The text was updated successfully, but these errors were encountered: