Skip to content

possible race conditions in blobs conversion #2346

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

Closed
tonistiigi opened this issue Sep 6, 2021 · 0 comments · Fixed by #2603
Closed

possible race conditions in blobs conversion #2346

tonistiigi opened this issue Sep 6, 2021 · 0 comments · Fixed by #2603
Assignees

Comments

@tonistiigi
Copy link
Member

While working on #2344 I noticed some possible issues with the blob conversion.

When new blob variant is added it is added as a label to the original blob. I think the labels should always be in all blobs. Eg. if there is a gzip blob that gets converted to zstd, now when a pull happens to the same zstd the same blob is used and connected to another ref. If that second ref is exported as gzip it should notice that this conversion already exists.

When there are multiple refs that share one of the blobs(main blob of one ref is secondary to another), now when one ref gets released the second one may have a link to it through blob label but not through lease. That means that between the blob lookup and add to the lease the blob might get deleted. One possibility would be to tie the different compressions of blob with gc labels so they can only be released together even if only some of them are part of a specific ref lease. There might be simpler solutions. Notice that Info() request does not guarantee that the return value still exists after it has returned.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants