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-16559 container: return EBUSY for container being destroyed #15154

Merged
merged 1 commit into from
Sep 20, 2024

Conversation

gnailzenh
Copy link
Contributor

  • Don't allow multiple callers to destroy the same container, later call should get EBUSY
  • Remove the loop in cont_child_destroy_one(), because it will wait for refcount dropping to zero, the loop is useless now.

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.

@gnailzenh gnailzenh requested review from a team as code owners September 19, 2024 08:05
Copy link

Ticket title is 'erasurecode/rebuild_fio.py:EcodFioRebuild.test_ec_online_rebuild_fio - daos_lru_ref_evict_wait() Assertion '!llink->ll_wait_evict' failed'
Status is 'Open'
Labels: '2.6.1rc1,md_on_ssd,weekly_test'
https://daosio.atlassian.net/browse/DAOS-16559

@daosbuild1
Copy link
Collaborator

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-15154/1/execution/node/295/log

@daosbuild1
Copy link
Collaborator

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-15154/1/execution/node/273/log

@daosbuild1
Copy link
Collaborator

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-15154/1/execution/node/354/log

@daosbuild1
Copy link
Collaborator

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-15154/1/execution/node/357/log

@daosbuild1
Copy link
Collaborator

@daosbuild1
Copy link
Collaborator

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-15154/1/execution/node/494/log

- Don't allow multiple callers to destroy the same container,
  later call should get EBUSY
- Remove the loop in cont_child_destroy_one(), because it will
  wait for refcount dropping to zero, the loop is useless now.

Signed-off-by: Liang Zhen <liang.zhen@intel.com>
gnailzenh added a commit that referenced this pull request Sep 19, 2024
)

- Don't allow multiple callers to destroy the same container,
  later call should get EBUSY
- Remove the loop in cont_child_destroy_one(), because it will
  wait for refcount dropping to zero, the loop is useless now.

Signed-off-by: Liang Zhen <liang.zhen@intel.com>
@daosbuild1
Copy link
Collaborator

Test stage Functional Hardware Medium completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15154/3/execution/node/1531/log

@phender
Copy link
Contributor

phender commented Sep 19, 2024

Test stage Functional Hardware Medium completed with status FAILURE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-15154/3/execution/node/1531/log

Multiple tests not run in HW Medium due to a possible DNS issue: https://build.hpdd.intel.com/job/daos-stack/job/daos/view/change-requests/job/PR-15154/3/artifact/Functional%20Hardware%20Medium/launch/functional_hardware_medium/results.html

2024/09/19 06:55:02 DEBUG                     run_remote: Running on wolf-[54,142-145] with a 120 second timeout: mount | grep -E 'type fuse.daos'
2024/09/19 06:55:02 DEBUG                log_result_data:   wolf-54 (rc=255): ssh: Could not resolve hostname wolf-54: Name or service not known
2024/09/19 06:55:02 DEBUG                log_result_data:   wolf-142 (rc=255): ssh: Could not resolve hostname wolf-142: Name or service not known
2024/09/19 06:55:02 DEBUG                log_result_data:   wolf-145 (rc=255): ssh: Could not resolve hostname wolf-145: Name or service not known
2024/09/19 06:55:02 DEBUG                log_result_data:   wolf-144 (rc=255): ssh: Could not resolve hostname wolf-144: Name or service not known
2024/09/19 06:55:02 DEBUG                log_result_data:   wolf-143 (rc=255): ssh: Could not resolve hostname wolf-143: Name or service not known

Manually kicked of a new build: https://build.hpdd.intel.com/job/daos-stack/job/daos/view/change-requests/job/PR-15154/4/

rc = cont_child_lookup(tls->dt_cont_cache, in->tdi_uuid,
in->tdi_pool_uuid, false /* create */, &cont);
if (rc == -DER_NONEXIST)
D_GOTO(out_pool, rc = 0);
Copy link
Contributor

Choose a reason for hiding this comment

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

If the container is in stopped state when a container destroy reaches here, the destroy will be skipped. I'm not quite sure if this could happen in today's implementation, but anyway, I think this kind of potential issues happened when target is in rebuild/reint is out of scope of this PR.

@@ -1375,7 +1363,7 @@ ds_cont_child_lookup(uuid_t pool_uuid, uuid_t cont_uuid,
if (rc != 0)
return rc;

if ((*ds_cont)->sc_stopping) {
if ((*ds_cont)->sc_stopping || (*ds_cont)->sc_destroying) {
Copy link
Contributor

Choose a reason for hiding this comment

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

[minor] sc_destroying check here is duplicated, cont_child_stop() will set sc_stopping anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

right, I think we should do more cleanup for this part of code.

@@ -2603,6 +2591,13 @@ cont_child_prop_update(void *data)
return rc;
}
D_ASSERT(child != NULL);
if (child->sc_stopping || child->sc_destroying) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This looks unnecessary for me, cont_child_lookup() will return ENOENT if it was stopped

@gnailzenh gnailzenh merged commit 531f522 into master Sep 20, 2024
54 of 55 checks passed
@gnailzenh gnailzenh deleted the liang/b_cont_destroy2 branch September 20, 2024 07:48
gnailzenh added a commit that referenced this pull request Sep 20, 2024
) (#15158)

- Don't allow multiple callers to destroy the same container,
  later call should get EBUSY
- Remove the loop in cont_child_destroy_one(), because it will
  wait for refcount dropping to zero, the loop is useless now.

Signed-off-by: Liang Zhen <liang.zhen@intel.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants