Skip to content
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 vos: discard invalid DTX when commit or abort - b26 #15901

Open
wants to merge 1 commit into
base: release/2.6
Choose a base branch
from

Conversation

Nasf-Fan
Copy link
Contributor

When commit or abort a DTX, we will check whether it is a valid entry or not. For invalid case, we will discard it with warning message and increase related metrics counter.

It may be not perfect solution, but it is efficient to help the user to cleanup system efficiently.

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:

  • You are the appropriate gatekeeper to be landing the patch.
  • The PR has 2 reviews by people familiar with the code, including appropriate owners.
  • Githooks were used. If not, request that user install them and check copyright dates.
  • Checkpatch issues are resolved. Pay particular attention to ones that will show up on future PRs.
  • All builds have passed. Check non-required builds for any new compiler warnings.
  • Sufficient testing is done. Check feature pragmas and test tags and that tests skipped for the ticket are run and now pass with the changes.
  • If applicable, the PR has addressed any potential version compatibility issues.
  • Check the target branch. If it is master branch, should the PR go to a feature branch? If it is a release branch, does it have merge approval in the JIRA ticket.
  • Extra checks if forced landing is requested
    • Review comments are sufficiently resolved, particularly by prior reviewers that requested changes.
    • No new NLT or valgrind warnings. Check the classic view.
    • Quick-build or Quick-functional is not used.
  • Fix the commit message upon landing. Check the standard here. Edit it to create a single commit. If necessary, ask submitter for a new summary.

Copy link

Ticket title is 'LRZ: m02r01s07dao engine coredumps with vos EMRG src/vos/ilog.c:411 ilog_open() Assertion'
Status is 'Awaiting Verification'
Labels: 'ALCF,LRZ,alcf_track,google-cloud-daos'
Job should run at elevated priority (1)
https://daosio.atlassian.net/browse/DAOS-16876

@github-actions github-actions bot added the priority Ticket has high priority (automatically managed) label Feb 13, 2025
@Nasf-Fan Nasf-Fan force-pushed the Nasf-Fan/DAOS-16876_discard_b26 branch from b8498f7 to 864a9de Compare February 13, 2025 18:56
@daosbuild1
Copy link
Collaborator

Test stage NLT on EL 8.8 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-15901/1/display/redirect

@daosbuild1
Copy link
Collaborator

Test stage NLT on EL 8.8 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-15901/2/display/redirect

@daosbuild1
Copy link
Collaborator

Test stage Unit Test on EL 8.8 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-15901/2/display/redirect

@daosbuild1
Copy link
Collaborator

Test stage Unit Test bdev with memcheck on EL 8.8 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-15901/2/display/redirect

@daosbuild1
Copy link
Collaborator

Test stage Unit Test with memcheck on EL 8.8 completed with status FAILURE. https://build.hpdd.intel.com/job/daos-stack/job/daos/job/PR-15901/2/display/redirect

@Nasf-Fan Nasf-Fan force-pushed the Nasf-Fan/DAOS-16876_discard_b26 branch from 864a9de to d700671 Compare February 13, 2025 20:02
@daosbuild1
Copy link
Collaborator

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

When commit or abort a DTX, we will check whether it is a valid
entry or not. For invalid case, we will discard it with warning
message and increase related metrics counter.

It may be not perfect solution, but it is efficient to help the
user to cleanup system efficiently.

Signed-off-by: Jeff Olivier <[email protected]>
Signed-off-by: Fan Yong <[email protected]>
@Nasf-Fan Nasf-Fan force-pushed the Nasf-Fan/DAOS-16876_discard_b26 branch from d700671 to 649a287 Compare February 14, 2025 03:03
if (rc == 0 && opc != ILOG_OP_UPDATE) {
if (version == ilog_mag2ver(lctx->ic_root->lr_magic)) {
D_WARN("ilog entry on %s doesn't exist\n", opc_str[opc]);
return -DER_NONEXIST;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't quite follow this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As my understand, when we commit or abort the ilog via dtx_{commit,abort}, if commit/abort succeed, then the version will bump. Here, if the version does not bump, then must be not found. @jolivier23 , is it your expected?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is correct. It means the entry is no longer in the ilog. This code is shared between abort, persist, and update (or insert) but only the former two need to remove the ilog entry from the dtx record

@@ -573,7 +574,7 @@ dtx_ilog_rec_release(struct umem_instance *umm, struct vos_container *cont,

ilog_close(loh);

if (rc != 0)
if (rc != 0 && rc != -DER_NONEXIST)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it too late to check DER_NONEXIST here? I suppose error is already returned when above ilog_open() failed, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Such log message is no matter, its caller do_dtx_rec_release() will print.

@Nasf-Fan Nasf-Fan marked this pull request as ready for review February 14, 2025 14:56
@Nasf-Fan Nasf-Fan requested review from a team as code owners February 14, 2025 14:56
@Nasf-Fan Nasf-Fan requested a review from janekmi February 14, 2025 14:58
Copy link
Contributor

@daltonbohning daltonbohning left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ftest LGTM

@Nasf-Fan
Copy link
Contributor Author

Please help to review the patch that is required for 2.6.3-rc4, thanks!

@Nasf-Fan Nasf-Fan requested a review from NiuYawei February 16, 2025 02:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority Ticket has high priority (automatically managed) release-2.6.4
Development

Successfully merging this pull request may close these issues.

5 participants