-
Notifications
You must be signed in to change notification settings - Fork 308
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DAOS-16876 dtx: misc fixes for DTX related logic #15942
Conversation
Ticket title is 'LRZ: m02r01s07dao engine coredumps with vos EMRG src/vos/ilog.c:411 ilog_open() Assertion' |
Test stage Functional Hardware Medium Verbs Provider completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15942/2/execution/node/1558/log |
Test stage Functional Hardware Medium completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15942/2/execution/node/1537/log |
1. Do not clear dae_need_release flag on DTX entry in DRAM until related local transaction has been successfully committed. Otherwise, it will skip subsequent DTX commit or abort this entry. 2. Do not allow the case that some DTX entry does not exist in DRAM but related modification target still references it. Add assertion check during vos_dtx_check_availability() and vos_dtx_deregister_record(). 3. Replace daos_gettime_coarse() with daos_wallclock_secs() for DTX time. Then DTX cleanup and DTX aggregation logic can use them after restart. 4. Bypass MRU operation during DTX LRU array lookup, that is unnecessary and may hide some potential bugs. Signed-off-by: Fan Yong <[email protected]>
a645830
to
fc052c9
Compare
Test stage Functional Hardware Medium completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15942/4/execution/node/1541/log |
Hit some hardware issue on wolf-216: |
pool-create test failure because of out of space on wolf-215: |
Restart CI test for the hardware related issues. |
@@ -825,9 +826,6 @@ dtx_rec_release(struct vos_container *cont, struct vos_dtx_act_ent *dae, bool ab | |||
UMOFF_P(dbd_off), DP_UUID(cont->vc_id)); | |||
} | |||
|
|||
if (rc == 0) | |||
dae->dae_need_release = 0; | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this the key change? The dae_need_release should be cleared after local tx committed instead of here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, originally we cleared such flag too early.
return ALB_AVAILABLE_CLEAN; | ||
} | ||
D_ASSERTF(found, "Non-committed DTX must be in active table: lid=%x, epoch=" | ||
DF_U64 ", boundary " DF_U64 "\n", entry, epoch, cont->vc_solo_dtx_epoch); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hmm, I'm wondering why we need to tolerate this before? Is it because of the bug you fixed in this PR or other reason?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It may because we wanted to make the system to be more robust at that time or related optimized/tolerated case has been removed. Anyway, consider current implementation, add assertion here will help us to detect corrupted DTX entry more early.
found = lrua_lookupx(vos_hdl2cont(coh)->vc_dtx_array, | ||
(entry & DTX_LID_SOLO_MASK) - DTX_LID_RESERVED, epoch, &dae); | ||
D_ASSERTF(found, "Could not find active DTX record for lid=%x, epoch=" DF_U64 "\n", | ||
entry, epoch); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question here, was there any other consideration on tolerating "!found" before? I'm worried that if deregister or check availability could be called before the in-memory tree is fully setup? (though that should not be tolerated as well).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Currently, we do not allow to access the DTX LRU array before its fully setup. So it is safe from this perspective.
Do not clear dae_need_release flag on DTX entry in DRAM until related local transaction has been successfully committed. Otherwise, it will skip subsequent DTX commit or abort this entry.
Do not allow the case that some DTX entry does not exist in DRAM but related modification target still references it. Add assertion check during vos_dtx_check_availability() and vos_dtx_deregister_record().
Replace daos_gettime_coarse() with daos_wallclock_secs() for DTX time. Then DTX cleanup and DTX aggregation logic can use them after restart.
Bypass MRU operation during DTX LRU array lookup, that is unnecessary and may hide some potential bugs.
Before requesting gatekeeper:
Features:
(orTest-tag*
) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.Gatekeeper: