DAOS-16809 vos: container based stable epoch #15605

Nasf-Fan · 2024-12-12T15:39:14Z

For the purpose of efficient calculating container based local stable epoch, we will maintain some kind of sorted list for active DTX entries with epoch order. But consider related overhead, it is not easy to maintain a strictly sorted list for all active DTX entries. For the DTX which leader resides on current target, its epoch is already sorted when generate on current engine. So the main difficulty is for those DTX entries which leaders are on remote targets.

On the other hand, the local stable epoch is mainly used to generate global stable epoch that is for incremental reintegration. In fact, we do not need a very accurate global stable epoch for incremental reintegration. It means that it is no matter (or non-fatal) if the calculated stable epoch is a bit smaller than the real case. For example, seconds error for the stable epoch almost can be ignored if we compare such overhead with rebuilding the whole target from scratch. So for the DTX entry which leader is on remote target, we will maintain it in the list with relative incremental trend based on the epoch instead of strict sorting the epoch. We introduce an O(1) algorithm to handle such unsorted DTX entries list for calculating local stable epoch.

Main VOS APIs for the stable epoch:

/* Calculate current locally known stable epoch for the given container. */ daos_epoch_t vos_cont_get_local_stable_epoch(daos_handle_t coh);

/* Get global stable epoch for the given container. */
daos_epoch_t vos_cont_get_global_stable_epoch(daos_handle_t coh);

/* Set global stable epoch for the given container. */
int vos_cont_set_global_stable_epoch(daos_handle_t coh, daos_epoch_t epoch);

Another important enhancement in the patch is about handling potential conflict between EC/VOS aggregation and delayed modification with very old epoch.

For standalone transaction, when it is started on the DTX leader, its epoch is generated by the leader, then the modification RPC will be forwarded to other related non-leader(s). If the forwarded RPC is delayed for some reason, such as network congestion or system busy on the non-leader, as to the epoch for such transaction becomes very old (exceed related threshold), as to VOS aggregation may has already aggregated related epoch range. Under such case, the non-leader will reject such modification to avoid data lost/corruption.

For distributed transaction, if there is no read (fetch, query, enumerate, and so on) before client commit_tx, then related DTX leader will generate epoch for the transaction after client commit_tx. Then it will be the same as above standalone transaction for epoch handling.

If the distributed transaction involves some read before client commit_tx, its epoch will be generated by the first accessed engine for read. If the transaction takes too long time after that, then when client commit_tx, its epoch may become very old as to related DTX leader will have to reject the transaction to avoid above mentioned conflict. And even if the DTX leader did not reject the transaction, some non-leader may also reject it because of the very old epoch. So it means that under such framework, the life for a distributed transaction cannot be too long. That can be adjusted via the server side environment variable DAOS_VOS_AGG_GAP. The default value is 60 seconds.

NOTE: EC/VOS aggregation should avoid aggregating in the epoch range where
lots of data records are pending to commit, so the aggregation epoch
upper bound is 'current HLC - vos_agg_gap'.

Before requesting gatekeeper:

Two review approvals and any prior change requests have been resolved.
Testing is complete and all tests passed or there is a reason documented in the PR why it should be force landed and forced-landing tag is set.
Features: (or Test-tag*) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.
Commit messages follows the guidelines outlined here.
Any tests skipped by the ticket being addressed have been run and passed in the PR.

Gatekeeper:

github-actions · 2024-12-12T15:39:33Z

Ticket title is 'DAOS local stable epoch'
Status is 'In Review'
Labels: 'Rebuild'
https://daosio.atlassian.net/browse/DAOS-16809

daosbuild1 · 2024-12-12T15:43:06Z

Test stage Build on Leap 15.5 with Intel-C and TARGET_PREFIX completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/1/execution/node/319/log

daosbuild1 · 2024-12-12T15:44:37Z

Test stage Build RPM on EL 9 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/1/execution/node/350/log

daosbuild1 · 2024-12-12T15:45:16Z

Test stage Build RPM on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/1/execution/node/301/log

daosbuild1 · 2024-12-12T15:49:09Z

Test stage Build RPM on Leap 15.5 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/1/execution/node/398/log

daosbuild1 · 2024-12-12T15:50:49Z

Test stage Build DEB on Ubuntu 20.04 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/1/execution/node/345/log

daosbuild1 · 2024-12-12T15:59:06Z

Test stage Build on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/1/execution/node/521/log

daosbuild1 · 2024-12-12T16:24:08Z

Test stage Build on Leap 15.5 with Intel-C and TARGET_PREFIX completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/2/execution/node/383/log

daosbuild1 · 2024-12-12T16:24:17Z

Test stage Build on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/2/execution/node/387/log

daosbuild1 · 2024-12-12T16:25:11Z

Test stage Build RPM on EL 9 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/2/execution/node/348/log

daosbuild1 · 2024-12-12T16:26:12Z

Test stage Build RPM on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/2/execution/node/356/log

daosbuild1 · 2024-12-12T16:28:04Z

Test stage Build RPM on Leap 15.5 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/2/execution/node/374/log

daosbuild1 · 2024-12-12T16:31:07Z

Test stage Build DEB on Ubuntu 20.04 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/2/execution/node/349/log

daosbuild1 · 2024-12-12T17:15:48Z

Test stage Unit Test bdev on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15605/4/testReport/

daosbuild1 · 2024-12-12T17:16:46Z

Test stage Unit Test on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15605/4/testReport/

daosbuild1 · 2024-12-12T17:21:01Z

Test stage Unit Test bdev with memcheck on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15605/4/testReport/

daosbuild1 · 2024-12-12T17:46:05Z

Test stage Unit Test with memcheck on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15605/4/testReport/

daosbuild1 · 2024-12-13T08:06:52Z

Test stage Unit Test bdev on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15605/6/testReport/

daosbuild1 · 2024-12-13T08:08:30Z

Test stage Unit Test on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15605/6/testReport/

daosbuild1 · 2024-12-13T08:11:39Z

Test stage Unit Test bdev with memcheck on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15605/6/testReport/

daosbuild1 · 2024-12-13T08:29:50Z

Test stage Unit Test with memcheck on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15605/6/testReport/

daosbuild1 · 2024-12-13T11:02:27Z

Test stage Unit Test bdev on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15605/7/testReport/

daosbuild1 · 2024-12-13T11:04:04Z

Test stage Unit Test on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15605/7/testReport/

daosbuild1 · 2024-12-13T11:06:39Z

Test stage Unit Test bdev with memcheck on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15605/7/testReport/

daosbuild1 · 2025-01-15T02:48:39Z

Test stage Build RPM on EL 8 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/18/execution/node/319/log

For the purpose of efficient calculating container based local stable epoch, we will maintain some kind of sorted list for active DTX entries with epoch order. But consider related overhead, it is not easy to maintain a strictly sorted list for all active DTX entries. For the DTX which leader resides on current target, its epoch is already sorted when generate on current engine. So the main difficulty is for those DTX entries which leaders are on remote targets. On the other hand, the local stable epoch is mainly used to generate global stable epoch that is for incremental reintegration. In fact, we do not need a very accurate global stable epoch for incremental reintegration. It means that it is no matter (or non-fatal) if the calculated stable epoch is a bit smaller than the real case. For example, seconds error for the stable epoch almost can be ignored if we compare such overhead with rebuilding the whole target from scratch. So for the DTX entry which leader is on remote target, we will maintain it in the list with relative incremental trend based on the epoch instead of strict sorting the epoch. We introduce an O(1) algorithm to handle such unsorted DTX entries list for calculating local stable epoch. Main VOS APIs for the stable epoch: /* Calculate current locally known stable epoch for the given container. */ daos_epoch_t vos_cont_get_local_stable_epoch(daos_handle_t coh); /* Get global stable epoch for the given container. */ daos_epoch_t vos_cont_get_global_stable_epoch(daos_handle_t coh); /* Set global stable epoch for the given container. */ int vos_cont_set_global_stable_epoch(daos_handle_t coh, daos_epoch_t epoch); Another important enhancement in the patch is about handling potential conflict between EC/VOS aggregation and delayed modification with very old epoch. For standalone transaction, when it is started on the DTX leader, its epoch is generated by the leader, then the modification RPC will be forwarded to other related non-leader(s). If the forwarded RPC is delayed for some reason, such as network congestion or system busy on the non-leader, as to the epoch for such transaction becomes very old (exceed related threshold), as to VOS aggregation may has already aggregated related epoch rang. Under such case, the non-leader will reject such modification to avoid data lost/corruption. For distributed transaction, if there is no read (fetch, query, enumerate, and so on) before client commit_tx, then related DTX leader will generate epoch for the transaction after client commit_tx. Then it will be the same as above standalone transaction for epoch handling. If the distributed transaction involves some read before client commit_tx, its epoch will be generated by the first accessed engine for read. If the transaction takes too long time after that, then when client commit_tx, its epoch may become very old as to related DTX leader will have to reject the transaction to avoid above mentioned conflict. And even if the DTX leader did not reject the transaction, some non-leader may also reject it because of the very old epoch. So it means that under such framework, the life for a distributed transaction cannot be too long. That can be adjusted via the server side environment variable DAOS_VOS_AGG_GAP. The default value is 60 seconds. NOTE: EC/VOS aggregation should avoid aggregating in the epoch range where lots of data records are pending to commit, so the aggregation epoch upper bound is 'current HLC - vos_agg_gap'. Signed-off-by: Fan Yong <[email protected]>

daosbuild1 · 2025-01-15T02:51:35Z

Test stage Build RPM on EL 9 completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15605/18/execution/node/359/log

NiuYawei · 2025-01-15T08:16:21Z

src/engine/sched.c

@@ -2241,6 +2240,8 @@ sched_run(ABT_sched sched)
 		return;
 	}

+	dx->dx_sched_info.si_agg_gap = (vos_get_agg_gap() + 10) * 1000; /* msecs */


Could you move this to sched_info_init()? Or remove the 'si_agg_gap'? I don't see why we need to duplicate this constant value in sched_info.

I can move it into sched_info_init(), but seems not too much difference. I am not sure what "duplicate" you mean. I have ever discussed with you that making such agg_gap as global variable will cause compile dependency trouble.

NiuYawei · 2025-01-15T08:22:23Z

src/include/daos_srv/container.h

+	 * The gap between the max allowed aggregation epoch and current HLC. The modification
+	 * with older epoch out of range may cause conflict with aggregation as to be rejected.
+	 */
+	uint64_t		 sc_agg_eph_gap;


Isn't it a global value? I don't see why it's per-container.

Put it in ds_cont_child just for using it easily when aggregation. I will consider a dss variable to replace that.

NiuYawei · 2025-01-15T08:24:21Z

src/container/srv_target.c

@@ -425,6 +429,9 @@ cont_child_aggregate(struct ds_cont_child *cont, cont_aggregate_cb_t agg_cb,
 		DP_CONT(cont->sc_pool->spc_uuid, cont->sc_uuid),
 		tgt_id, epoch_range.epr_lo, epoch_range.epr_hi);

+	if (!param->ap_vos_agg)
+		vos_cont_set_mod_bound(cont->sc_hdl, epoch_range.epr_hi);


Why do we need to set this value here and there? Isn't it a global constant value 'cur_time - gap'? I don't see why it's related to aggregation range.

If aggregation run slowly, much behind of current HLC, it is unnecessary to restart the DTX which epoch is out of 'cur_time - gap' but newer than current aggregation boundary. We only need to guarantee that the DTX's epoch is not smaller than current aggregation real boundary.

I see, thanks. but I don't think this optimization is necessary though. :)

NiuYawei · 2025-01-15T08:25:04Z

src/dtx/dtx_common.c

@@ -1853,6 +1855,8 @@ dtx_cont_register(struct ds_cont_child *cont)
 		D_GOTO(out, rc = -DER_NOMEM);
 	}

+	cont->sc_agg_eph_gap = d_sec2hlc(vos_get_agg_gap());


I think it's not necessary to duplicate a constant value for each container.

I will consider a dss variable to replace that.

NiuYawei · 2025-01-15T08:33:37Z

src/tests/ftest/util/server_utils_params.py

@@ -436,6 +436,7 @@ class EngineYamlParameters(YamlParameters):
            "D_LOG_FILE_APPEND_PID=1",
            "DAOS_POOL_RF=4",
            "CRT_EVENT_DELAY=1",
+            "DAOS_VOS_AGG_GAP=25",


Shouldn't we use this value (used by CI) as default and tune the value on larger system when necessary?

NiuYawei · 2025-01-15T08:48:55Z

src/vos/vos_internal.h

+	 * pressure, the EC/VOS aggregation up boundary may be higher than vc_local_stable_epoch,
+	 * then it will cause vc_mod_epoch_bound > vc_local_stable_epoch.
+	 */
+	daos_epoch_t		vc_mod_epoch_bound;


I don't quite follow so many various variables, it looks to me there are only two things:

constant gap between current HLC and EC aggregation upper bound, any write with lower epoch (lower than aggregation upper bound) will be rejected. (write with "epoch < current HLC - gap" will be rejected)

per-container persistent stable epoch, which is min(uncommitted dtx epoch, agg upper bound epoch).

Did I miss anything?

constant gap between current HLC and EC aggregation upper bound, any write with lower epoch (lower than aggregation upper bound) will be rejected. (write with "epoch < current HLC - gap" will be rejected)

Such way can work, but may cause too much transaction restart unnecessarily. In fact, we only need to guarantee that no modification will be older than aggregation boundary.

per-container persistent stable epoch, which is min(uncommitted dtx epoch, agg upper bound epoch).

That is only in theory, but it is not easy maintain DTX epoch order efficiently, we do not know which one is "min".

I see why this variable was introduced now, though I don't think this optimization is necessary. :)

Nasf-Fan · 2025-01-15T09:59:12Z

Shouldn't we use this value (used by CI) as default and tune the value on larger system when necessary?

I do not think so, simplifying user configuration is more important than CI test.

Signed-off-by: Fan Yong <[email protected]>

Nasf-Fan · 2025-01-15T10:21:19Z

I refreshed the patch with removing your concern about "agg_gap". @NiuYawei

NiuYawei · 2025-01-16T03:33:46Z

src/container/srv_target.c

@@ -425,6 +429,9 @@ cont_child_aggregate(struct ds_cont_child *cont, cont_aggregate_cb_t agg_cb,
 		DP_CONT(cont->sc_pool->spc_uuid, cont->sc_uuid),
 		tgt_id, epoch_range.epr_lo, epoch_range.epr_hi);

+	if (!param->ap_vos_agg)
+		vos_cont_set_mod_bound(cont->sc_hdl, epoch_range.epr_hi);


I see, thanks. but I don't think this optimization is necessary though. :)

NiuYawei · 2025-01-16T03:49:47Z

src/vos/vos_container.c

+	 * It is not easy to know which DTX is the oldest one in the unsorted list.
+	 * The one after the header in the list maybe older than the header. But the
+	 * epoch difference will NOT exceed 'vos_agg_gap' since any DTX with older
+	 * epoch will be rejected (and restart with newer epoch).


I don't quite follow this.

See the logic in vos_dtx_alloc(), if new added DTX's epoch is older than the tail one, the vc_mod_epoch_bound will be refreshed to guarantee the GAP restriction.

I see it now, thank for the explanation.

NiuYawei · 2025-01-16T04:46:52Z

src/vos/vos_container.c

+	 * may be over-estimated. Usually, the count of re-indexed DTX entries is quite
+	 * limited, and will be purged soon after the container opened (via DTX resync).
+	 * So it will not much affect the local stable epoch calculation.
+	 */


The uncommitted dtx entry could be linked in reindex list only? I'm not sure why the 'stable epoch' is related to 'reindex'.

For those originally unsorted ones, they will be linked into unsorted list. The DTX entries to be reindexed are uncommitted, their epoch will affect the local stable epoch that cannot exceed the lowest epoch of them.

I see, thanks.

NiuYawei · 2025-01-16T04:48:11Z

src/vos/vos_container.c

+	 * is older, then reuse the former one.
+	 */
+	if (unlikely(epoch < cont->vc_local_stable_epoch))
+		epoch = cont->vc_local_stable_epoch;


How can this happen, bug? Then I think we'd trigger an assert (or at least print error message).

Not bug, consider the following case:
Two DTX entries in the unsorted list, assume DTX1's epoch is 100, DTX2's epoch is 90. The first time of get_local_stable_epoch, the calculated one 100 - GAP, then DTX1 is committed, and then another get_local_stable_epoch is called, then the new calculated stable epoch is 90 - GAP, that is older than the former one.

NiuYawei · 2025-01-16T04:50:17Z

src/vos/vos_container.c

+	 * acceptable after reporting the new local stable epoch. The semantics maybe so
+	 * strict as to a lot of DTX restart.
+	 */
+	if (cont->vc_mod_epoch_bound < epoch) {


Why this "vc_mod_epoch_bound" is related to "stable epoch"?

We use vc_mod_epoch_bound to control whether accept new modification, if it is older than stable epoch, then the stable epoch is not "stable", that will break incremental reintegration semantics.

NiuYawei · 2025-01-16T04:53:05Z

src/vos/vos_container.c

+	}
+
+	if (unlikely(cont_ext->ced_global_stable_epoch > epoch)) {
+		D_WARN("Do not allow to rollback global stable epoch from "


NiuYawei · 2025-01-16T04:56:50Z

src/vos/vos_dtx.c

+
+	if (!dth->dth_epoch_owner && !d_list_empty(&cont->vc_dtx_unsorted_list)) {
+		dae = d_list_entry(cont->vc_dtx_unsorted_list.prev, struct vos_dtx_act_ent,
+				   dae_order_link);


I don't quite follow why rejecting old epoch need to check the active dtx in unsorted list?

To guarantee the rules of calculating local stable epoch.

NiuYawei · 2025-01-16T05:03:38Z

src/vos/vos_dtx.c

+				 *
+				 * This is an O(N) algorithm. N is the count of DTX entries to be
+				 * re-indexed. Please reference vos_cont_get_local_stable_epoch().
+				 */


I suppose reindex just load dtx entries from pmem, and re-create index in DRAM? So should it just reuse the same mechanism/code used for normal active dtx tracking? I don't see why extra processing is required for reindex?

Because the user/admin may configure different "GAP" when restart the engines. Means the DTX entries may have different "GAP" when they were generated.

NiuYawei · 2025-01-16T05:05:16Z

src/vos/vos_internal.h

+	 * pressure, the EC/VOS aggregation up boundary may be higher than vc_local_stable_epoch,
+	 * then it will cause vc_mod_epoch_bound > vc_local_stable_epoch.
+	 */
+	daos_epoch_t		vc_mod_epoch_bound;


I see why this variable was introduced now, though I don't think this optimization is necessary. :)

NiuYawei · 2025-01-16T05:11:15Z

src/tests/ftest/util/server_utils_params.py

@@ -436,6 +436,7 @@ class EngineYamlParameters(YamlParameters):
            "D_LOG_FILE_APPEND_PID=1",
            "DAOS_POOL_RF=4",
            "CRT_EVENT_DELAY=1",
+            "DAOS_VOS_AGG_GAP=25",


It looks to me not quite right if we don't test default configuration in CI hardware tests. If the default value won't work well on extreme large system like Aurora, I think it's acceptable to ask user to configure a larger value (via server yaml).

Nasf-Fan · 2025-01-16T12:22:59Z

I see, thanks. but I don't think this optimization is necessary though. :)

The basic policy is that try to avoid restarting the DTX as much as possible.

It looks to me not quite right if we don't test default configuration in CI hardware tests. If the default value won't work well on extreme large system like Aurora, I think it's acceptable to ask user to configure a larger value (via server yaml).

Current set (25 seconds) in the patch is try to make the CI test to have the similar behavior as without the patch. If we use the default configuration (60 seconds), we may miss a lot of race windows with aggregation. That may cause some bugs to be hidden.

NiuYawei · 2025-01-16T12:59:49Z

src/vos/vos_container.c

+	 * It is not easy to know which DTX is the oldest one in the unsorted list.
+	 * The one after the header in the list maybe older than the header. But the
+	 * epoch difference will NOT exceed 'vos_agg_gap' since any DTX with older
+	 * epoch will be rejected (and restart with newer epoch).


I see it now, thank for the explanation.

NiuYawei · 2025-01-16T13:14:38Z

src/vos/vos_container.c

+	 * may be over-estimated. Usually, the count of re-indexed DTX entries is quite
+	 * limited, and will be purged soon after the container opened (via DTX resync).
+	 * So it will not much affect the local stable epoch calculation.
+	 */


I see, thanks.

NiuYawei · 2025-01-16T13:15:51Z

src/vos/vos_container.c

+	 * is older, then reuse the former one.
+	 */
+	if (unlikely(epoch < cont->vc_local_stable_epoch))
+		epoch = cont->vc_local_stable_epoch;


Resolve some merge conflict for copyright. Skip-test: true Skip-unit-tests: true Skip-nlt: true Skip-func-test: true Signed-off-by: Fan Yong <[email protected]>

Nasf-Fan · 2025-01-17T01:54:53Z

Resolve some merge conflict for copyright.

Nasf-Fan · 2025-01-17T01:55:49Z

@mchaarawi, any suggestion for the patch? Thanks!

liuxuezhao

can it be landed without waiting another round of test again?

gnailzenh · 2025-01-17T02:23:37Z

Sure, since only copyright is changed, it's ok to skip retest

Nasf-Fan force-pushed the Nasf-Fan/DAOS-16809_1 branch from 42a21a8 to 96716b9 Compare December 12, 2024 16:20

Nasf-Fan force-pushed the Nasf-Fan/DAOS-16809_1 branch 2 times, most recently from 1bdab81 to 128319b Compare December 12, 2024 16:48

Nasf-Fan force-pushed the Nasf-Fan/DAOS-16809_1 branch 2 times, most recently from 1db207f to eead8cc Compare December 13, 2024 07:42

Nasf-Fan force-pushed the Nasf-Fan/DAOS-16809_1 branch from eead8cc to f3368e7 Compare December 13, 2024 10:34

Nasf-Fan force-pushed the Nasf-Fan/DAOS-16809_1 branch from cd6f8c0 to 7aa0703 Compare January 15, 2025 02:51

liuxuezhao previously approved these changes Jan 15, 2025

View reviewed changes

jolivier23 previously approved these changes Jan 15, 2025

View reviewed changes

NiuYawei requested changes Jan 15, 2025

View reviewed changes

DAOS-16809 engine: fix for review feedback

1245805

Signed-off-by: Fan Yong <[email protected]>

Nasf-Fan dismissed stale reviews from jolivier23 and liuxuezhao via 1245805 January 15, 2025 10:20

Nasf-Fan requested a review from NiuYawei January 15, 2025 10:21

NiuYawei requested changes Jan 16, 2025

View reviewed changes

NiuYawei previously approved these changes Jan 16, 2025

View reviewed changes

liuxuezhao previously approved these changes Jan 16, 2025

View reviewed changes

Merge branch 'master' into Nasf-Fan/DAOS-16809_1

021833f

Resolve some merge conflict for copyright. Skip-test: true Skip-unit-tests: true Skip-nlt: true Skip-func-test: true Signed-off-by: Fan Yong <[email protected]>

Nasf-Fan dismissed stale reviews from liuxuezhao and NiuYawei via 021833f January 17, 2025 01:53

Nasf-Fan requested review from jolivier23, NiuYawei and liuxuezhao January 17, 2025 01:54

NiuYawei approved these changes Jan 17, 2025

View reviewed changes

liuxuezhao approved these changes Jan 17, 2025

View reviewed changes

gnailzenh merged commit 4e0f123 into master Jan 17, 2025
45 of 46 checks passed

gnailzenh deleted the Nasf-Fan/DAOS-16809_1 branch January 17, 2025 02:23

DAOS-16809 vos: container based stable epoch #15605

DAOS-16809 vos: container based stable epoch #15605

Conversation

Nasf-Fan commented Dec 12, 2024 • edited Loading

Before requesting gatekeeper:

Gatekeeper:

github-actions bot commented Dec 12, 2024 • edited Loading

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 12, 2024

daosbuild1 commented Dec 13, 2024

daosbuild1 commented Dec 13, 2024

daosbuild1 commented Dec 13, 2024

daosbuild1 commented Dec 13, 2024

daosbuild1 commented Dec 13, 2024

daosbuild1 commented Dec 13, 2024

daosbuild1 commented Dec 13, 2024

daosbuild1 commented Jan 15, 2025

daosbuild1 commented Jan 15, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nasf-Fan commented Jan 15, 2025

Nasf-Fan commented Jan 15, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nasf-Fan commented Jan 16, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Nasf-Fan commented Jan 17, 2025

Nasf-Fan commented Jan 17, 2025

liuxuezhao left a comment

Choose a reason for hiding this comment

gnailzenh commented Jan 17, 2025

Nasf-Fan commented Dec 12, 2024 •

edited

Loading

github-actions bot commented Dec 12, 2024 •

edited

Loading