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

Replicas can be restaged to a higher (slower) tier #239

Closed
alanking opened this issue Dec 14, 2023 · 2 comments
Closed

Replicas can be restaged to a higher (slower) tier #239

alanking opened this issue Dec 14, 2023 · 2 comments
Assignees
Labels
Milestone

Comments

@alanking
Copy link
Contributor

alanking commented Dec 14, 2023

Bug Report

iRODS Version, OS and Version

iRODS server: 4.3.1
Storage tiering plugin: 4.3.1

What did you try to do?

A test introduced in #234 revealed this issue. Here's the setup:

Have 3 resources which are configured as tiers in the same group:

  • ufs0 - tier 0
  • ufs1 - tier 1
  • ufs2 - tier 2

Set preserve_replicas to true on ufs0.
Set minimum_restage_tier to true on ufs1.

  1. Put an object on ufs0.
  2. Tier out to ufs2. There should be a replica 0 on ufs0 and a replica 2 on ufs2.
  3. Run iget -R ufs0 on the object.

Expected behavior

After discussing with team, the expected behavior is for nothing to happen. The replica that was fetched is already on a lower (faster) tier than the minimum restage tier, so there is no benefit to restaging it to the higher (slower) tier.

Observed behavior (including steps to reproduce, if applicable)

Replica 3 appears on ufs1, restaged from ufs0.

The restaging logic needs to ensure that the minimum restage tier is lower than the tier from which the replica is being restaged.

@alanking alanking added the bug label Dec 14, 2023
@alanking
Copy link
Contributor Author

Looks like this check needs to be expanded to include data which is on a lower tier than the minimum restage tier:

// do not queue movement if data is on minimum tier
// TODO:: query for already queued movement?
if(low_tier_resource_name == _source_resource) {
return;
}

@trel
Copy link
Member

trel commented Dec 14, 2023

Agreed. Check more scenarios, and return early.

@alanking alanking self-assigned this Dec 15, 2023
@alanking alanking added this to the 4.3.1.1 milestone Dec 15, 2023
alanking added a commit to alanking/irods_capability_storage_tiering that referenced this issue Dec 20, 2023
When a replica on a tier which is lower than the minimum restage tier
is scheduled for restaging, it should not move to the minimum restage
tier because that would entail restaging to a higher (slower) tier which
defeats the purpose of a restage.
alanking added a commit to alanking/irods_capability_storage_tiering that referenced this issue Dec 20, 2023
This commit gets the tier for the source resource and minimum restage
tier and compares them before attempting a restage. If the source resource
is in a tier that is lower than the minimum restage tier, the data
migration for the restage should be skipped.
alanking added a commit that referenced this issue Dec 20, 2023
When a replica on a tier which is lower than the minimum restage tier
is scheduled for restaging, it should not move to the minimum restage
tier because that would entail restaging to a higher (slower) tier which
defeats the purpose of a restage.
alanking added a commit that referenced this issue Dec 20, 2023
This commit gets the tier for the source resource and minimum restage
tier and compares them before attempting a restage. If the source resource
is in a tier that is lower than the minimum restage tier, the data
migration for the restage should be skipped.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

2 participants