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.

Sign up for GitHub

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

Jump to bottom

Implement backoff when retrying dsmc operations #21

Open
ZNikke opened this issue Sep 12, 2019 · 0 comments
Open

Implement backoff when retrying dsmc operations #21

ZNikke opened this issue Sep 12, 2019 · 0 comments
Assignees
@ZNikke

Comments

@ZNikke
Copy link
Collaborator

ZNikke commented Sep 12, 2019

Currently all retries of dsmc operations are done after a fixed retry period.

In cases where big operations fail (ie. due to server malfunction, broken tape, etc) this can result in logs filling up when using the default retry delay of 60 seconds.

Investigate if we can do exponential backoff on "large" failures, should be identifiable with either dsmc return codes/messages or simply by realising that we're retrying the same files over and over...
@ZNikke ZNikke self-assigned this Sep 12, 2019
ZNikke added a commit that referenced this issue Oct 8, 2019
@ZNikke
tsm_getvolumecontent: Don't skip damaged files(2)
09f46cd 
The fix in commit f866fb0 to not skip
damaged files turned out to be incomplete.

If a volume was flagged access=unavailable or similar then files on it
would not be included and we would see very frequent retries.

This commit changes the volume list retrieval to only ignore volumes that
are empty or are pending (ie. empty/reclaimed but on deletion hold due to
storage pool reusedelay!=0).

Should also reduce the impact of #21
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ZNikke ZNikke

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@ZNikke