common: 2.1.3-rc1 release #32

osalyk · 2026-01-14T08:34:11Z

This change is

Signed-off-by: Oksana Salyk <[email protected]>

... chunk reinit Issue Huge memory blocks with the header chunk of type CHUNK_TYPE_FREE had not reinitialized their footer chunk. Context - Allocator divides the available space into zones and zones into smaller chunks. - All chunk headers belonging to a single zone are stored in an array. - Chunk header describes its: type, size_idx and flags. - Chunk can be of a few types. The types important for this patch are: CHUNK_TYPE_FOOTER, CHUNK_TYPE_FREE, and CHUNK_TYPE_USED. - CHUNK_TYPE_FREE and _USED are chunk types marking the beginning of so called huge memory block. This means this chunk and a number of chunks following it (size_idx) constitues a single allocation or a free memory. - The last chunk belonging to a huge memory block ought to be of type CHUNK_TYPE_FOOTER. Its size_idx allows to easily find the first chunk belonging to this huge memory block and determine the huge memory block type. - Huge memory blocks' footers are written immediately but persited lazily. It is not a problem at runtime since the footers are there at runtime. But in case of a crash the footers may be not persisted properly and missing on open. So, when the allocator is booted up it recreates footers just in case any of them is missing. Note: The huge memory block's first chunk header and the last chunk header (footer) are not written nor persisted in any way transactionally. The first chunk header occupies only 8 bytes so it is written and persisted atomically. But its footer is written independently and not explicitly persisted. Note: The first chunk header contains all the required info to recreate footer. The last chunk header is there only to make huge memory blocks coalescing easier to compute. Reading the footer allows to immediately find the memory block leaving just before the memory block which neighbours one might want to find. This patch makes sure the huge memory block's footer is recreated no matter whather its type is CHUNK_TYPE_FREE or CHUNK_TYPE_USED. The patch is inspired by work done for DAOS' DAV allocator (DAOS-18195) which is heavily based on the PMEMOBJ allocator. Signed-off-by: Jan Michalski <[email protected]> Inspired-by: Sherin T George <[email protected]>

Signed-off-by: Oksana Salyk <[email protected]>

Signed-off-by: liuxiang <[email protected]>

Signed-off-by: Oksana Salyk <[email protected]> Co-authored-by: Jan Michalski <[email protected]>

DAOS-18296 Signed-off-by: Jan Michalski <[email protected]>

Signed-off-by: Oksana Salyk <[email protected]>

janekmi

@janekmi reviewed 48 files and all commit messages, and made 11 comments.
Reviewable status: all files reviewed, 11 unresolved discussions (waiting on @grom72 and @osalyk).

src/test/pmempool_sync/TEST43 line 17 at r1 (raw file):

require_real_pmem
require_test_type medium
require_fs_type non-pmem

Ups. It seems both pmem and non-pmem requirements are still here. What just happened? I thought all of these are just cherry picks?

Code quote:

require_real_pmem
require_test_type medium
require_fs_type non-pmem

src/test/pmempool_sync/TEST45 line 20 at r1 (raw file):

require_real_pmem
require_test_type medium
require_fs_type non-pmem

.

Code quote:

require_real_pmem
require_test_type medium
require_fs_type non-pmem

src/test/pmempool_sync/TEST47 line 21 at r1 (raw file):

require_real_pmem
require_test_type medium
require_fs_type non-pmem

.

Code quote:

require_real_pmem
require_test_type medium
require_fs_type non-pmem

src/test/pmempool_sync/TEST44 line 22 at r1 (raw file):

require_real_pmem
require_test_type medium
require_fs_type non-pmem

.

Code quote:

require_real_pmem
require_test_type medium
require_fs_type non-pmem

src/test/pmempool_sync/TEST48 line 24 at r1 (raw file):

require_real_pmem
require_test_type medium
require_fs_type non-pmem

.

Code quote:

require_real_pmem
require_test_type medium
require_fs_type non-pmem

src/test/pmempool_sync/TEST51 line 26 at r1 (raw file):

require_real_pmem
require_test_type medium
require_fs_type non-pmem

.

Code quote:

require_real_pmem
require_test_type medium
require_fs_type non-pmem

src/test/pmempool_sync/TEST52 line 21 at r1 (raw file):

require_real_pmem
require_test_type medium
require_fs_type non-pmem

.

Code quote:

require_real_pmem
require_test_type medium
require_fs_type non-pmem

src/test/pmempool_sync/TEST53 line 23 at r1 (raw file):

require_real_pmem
require_test_type medium
require_fs_type non-pmem

.

Code quote:

require_real_pmem
require_test_type medium
require_fs_type non-pmem

src/test/pmempool_sync/TEST46 line 20 at r1 (raw file):

require_real_pmem
require_test_type medium
require_fs_type non-pmem

.

Code quote:

require_real_pmem
require_test_type medium
require_fs_type non-pmem

src/test/pmempool_sync/TEST49 line 25 at r1 (raw file):

require_real_pmem
require_test_type medium
require_fs_type non-pmem

.

Code quote:

require_real_pmem
require_test_type medium
require_fs_type non-pmem

src/test/pmempool_sync/TEST50 line 25 at r1 (raw file):

require_real_pmem
require_test_type medium
require_fs_type non-pmem

.

Code quote:

require_real_pmem
require_test_type medium
require_fs_type non-pmem

osalyk

@osalyk made 11 comments.
Reviewable status: all files reviewed, 11 unresolved discussions (waiting on @grom72 and @janekmi).

src/test/pmempool_sync/TEST43 line 17 at r1 (raw file):