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

fix: quorum requirement for DeleteMarkers and parity upgraded objects #14248

Merged
merged 1 commit into from
Feb 4, 2022

Conversation

harshavardhana
Copy link
Member

@harshavardhana harshavardhana commented Feb 3, 2022

Description

fix: quorum requirement for DeleteMarkers and parity upgraded objects

Motivation and Context

DeleteMarkers do not have a default quorum, i.e it is possible that
DeleteMarkers were created with n/2+1 quorum as well to make sure
that we satisfy situations such as those we need to make sure delete
markers only expect n/2 read quorum.

Additionally, we should also look at additional metadata on the
actual objects that might have been "erasure" upgraded with new
parity when disks are down.

In such a scenario do not default to the standard storage class
parity, instead use the parityBlocks present on the FileInfo to
ensure that we are dealing with the correct quorum for READs and
DELETEs.

How to test this PR?

Few datasets are needed for example
inspect.324c74d9.zip
inspect.384b43df.zip

Without this fix, these objects shall return 503 quorum error, however with this fix you shall
see they all succeeding.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Optimization (provides speedup with no functional changes)
  • Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

  • Fixes a regression (If yes, please add commit-id or PR # here)
  • Documentation updated
  • Unit tests added/updated

DeleteMarkers do not have a default quorum, i.e it is possible that
DeleteMarkers were created with n/2+1 quorum as well to make sure
that we satisfy situations such as those we need to make sure delete
markers only expect n/2 read quorum.

Additionally we should also look at additional metadata on the
actual objects that might have been "erasure" upgraded with new
parity when disks are down.

In such a scenario do not default to the standard storage class
parity, instead use the parityBlocks present on the FileInfo to
ensure that we are dealing with the correct quorum for READs and
DELETEs.
@minio-trusted
Copy link
Contributor

Mint Automation

Test Result
mint-large-bucket.sh ✔️
mint-fs.sh ✔️
mint-gateway-s3.sh ✔️
mint-erasure.sh ✔️
mint-dist-erasure.sh ✔️
mint-gateway-nas.sh ✔️
mint-compress-encrypt-dist-erasure.sh ✔️
mint-pools.sh ✔️
Deleting image on docker hub
Deleting image locally

Copy link
Member

@vadmeste vadmeste left a comment

Choose a reason for hiding this comment

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

LGTM

Copy link
Contributor

@klauspost klauspost left a comment

Choose a reason for hiding this comment

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

👍🏼 In general relying on default parity will lead to bugs when reading (since it obviously is variable). Writing of course knows which quorum to expect.

@harshavardhana harshavardhana merged commit 0256dae into minio:master Feb 4, 2022
@harshavardhana harshavardhana deleted the fix-quorum branch February 4, 2022 10:47
harshavardhana added a commit to harshavardhana/minio that referenced this pull request Feb 9, 2022
Deleting bulk objects had an issue since the relevant versionID
is not passed through the layers to ensure that the dangling
object purge actually works cleanly.

This is a continuation of quorum related error returned by
multi-object delete API from minio#14248

This PR ensures that we pass down correct information as
well as extend the scope of dangling object detection.
harshavardhana added a commit to harshavardhana/minio that referenced this pull request Feb 9, 2022
Deleting bulk objects had an issue since the relevant versionID
is not passed through the layers to ensure that the dangling
object purge actually works cleanly.

This is a continuation of quorum related error returned by
multi-object delete API from minio#14248

This PR ensures that we pass down correct information as
well as extend the scope of dangling object detection.
harshavardhana added a commit to harshavardhana/minio that referenced this pull request Feb 9, 2022
Deleting bulk objects had an issue since the relevant versionID
is not passed through the layers to ensure that the dangling
object purge actually works cleanly.

This is a continuation of quorum related error returned by
multi-object delete API from minio#14248

This PR ensures that we pass down correct information as
well as extend the scope of dangling object detection.
harshavardhana added a commit to harshavardhana/minio that referenced this pull request Feb 9, 2022
Deleting bulk objects had an issue since the relevant versionID
is not passed through the layers to ensure that the dangling
object purge actually works cleanly.

This is a continuation of quorum related error returned by
multi-object delete API from minio#14248

This PR ensures that we pass down correct information as
well as extend the scope of dangling object detection.
harshavardhana added a commit to harshavardhana/minio that referenced this pull request Feb 9, 2022
Deleting bulk objects had an issue since the relevant versionID
is not passed through the layers to ensure that the dangling
object purge actually works cleanly.

This is a continuation of quorum related error returned by
multi-object delete API from minio#14248

This PR ensures that we pass down correct information as
well as extend the scope of dangling object detection.
harshavardhana added a commit to harshavardhana/minio that referenced this pull request Feb 9, 2022
Deleting bulk objects had an issue since the relevant versionID
is not passed through the layers to ensure that the dangling
object purge actually works cleanly.

This is a continuation of quorum related error returned by
multi-object delete API from minio#14248

This PR ensures that we pass down correct information as
well as extend the scope of dangling object detection.
harshavardhana added a commit that referenced this pull request Feb 9, 2022
…s() (#14273)

Deleting bulk objects had an issue since the relevant versionID
is not passed through the layers to ensure that the dangling
object purge actually works cleanly.

This is a continuation of quorum related error returned by
multi-object delete API from #14248

This PR ensures that we pass down correct information as
well as extend the scope of dangling object detection.
@bh4t bh4t added the bugfix label Jun 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants