Issue: 109: Checkpointing for HomeObject

[yamingk]

Changes.

1. Allow HomeObject to participant checkpointing.
2. Created dirty list for PG SB, which currently is empty. Any dirty candidate that want to join CP can be added to the same place or any place that makes sense for the author.
3. Some refactor change to test files
4. convert existing blob_id maintenance to CP (replace periodic timer, but not a must)

Testing:

1. Added a basic CP test for create a PG/Shard and put some random data in the dirty PG
2. trigger cp
3. restart homestore and assert the PG recovered should have the same dirtied value set before restart.
4. Test passed.

[codecov-commenter]

Codecov Report

Attention: 13 lines in your changes are missing coverage. Please review.

Comparison is base (68d9b2d) 78.06% compared to head (82968cd) 77.88%.

Files	Patch %	Lines
src/lib/homestore_backend/hs_blob_manager.cpp	60.00%	5 Missing and 1 partial ⚠️
src/lib/homestore_backend/hs_hmobj_cp.cpp	77.77%	4 Missing and 2 partials ⚠️
src/lib/homestore_backend/hs_homeobject.hpp	93.33%	0 Missing and 1 partial ⚠️

❗ Your organization needs to install the Codecov GitHub app to enable full functionality.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #115      +/-   ##
==========================================
- Coverage   78.06%   77.88%   -0.18%     
==========================================
  Files          29       30       +1     
  Lines        1217     1266      +49     
  Branches      127      130       +3     
==========================================
+ Hits          950      986      +36     
- Misses        199      208       +9     
- Partials       68       72       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[JacksonYao287]

@yamingk
1 we already have a timer for flushing pg super block periodically, if we have CP for homeobject, we could remove that timer.

2 the dirty list can not guarantee that it will be flushed to disk(crash before trigger_cp_flush), so we need a separate log to make sure all the updates will be recovered when restart. if we use cp for homeobject, we should implement that log, right?

[yamingk]

@JacksonYao287
| >>>>1. we already have a timer for flushing pg super block periodically, if we have CP for homeobject, we could remove that timer.
As was discussed in HS meeting, @raakella1 is going to combine the timer with CP.

| >>>>> 2 the dirty list can not guarantee that it will be flushed to disk(crash before trigger_cp_flush), so we need a separate log to make sure all the updates will be recovered when restart. if we use cp for homeobject, we should implement that log, right?
yes. Everything writing to CP has to be protected by log unless the consumer are aware of it and want to garunteen the idompotency itself.

[raakella1]

Minor comment, just for knowledge purpose, LG otherwise

[JacksonYao287]

is this safe to copy sizeof(pg_members) * num_members bytes to members, which can hold only one pg_members?

[yamingk]

The idea behind the original author is that members is always come from the heap, and its pointed size is always the size of num_members.

[JacksonYao287]

i prefer to remove copy , and overwrite operator new for pg_info_superblk. i think it will be more readable

[raakella1]

LG!