Skip to content

storage: GetBlob: write to a local tempfile#1167

Merged
lsm5 merged 1 commit intocontainers:masterfrom
vrothberg:getblob-optimization
Mar 2, 2021
Merged

storage: GetBlob: write to a local tempfile#1167
lsm5 merged 1 commit intocontainers:masterfrom
vrothberg:getblob-optimization

Conversation

@vrothberg
Copy link
Member

@vrothberg vrothberg commented Mar 2, 2021

When reading blobs (e.g., layers) from the storage, write the data to a
temporary file first and return its file descriptor.

The main goal is to keep the time of the storage being locked as short
as possible. With this approach we are disk-bound which is generally
faster than being network bound.

The motivation for this change is the desire to allow for accessing the
storage during pushes. We have attempted to optimize certain execution
paths in containers/storage but those require the callers to know
whether data will be manipulated or read, which is far from being
trivial. The daemon-less nature of the storage also requires to write
certain data.

This approach here is entirely transparent to the storage.

Signed-off-by: Valentin Rothberg rothberg@redhat.com

@vrothberg
Copy link
Member Author

vrothberg commented Mar 2, 2021

@rhatdan @giuseppe @nalind @lsm5 PTAL

@rhatdan
Copy link
Member

rhatdan commented Mar 2, 2021

LGTM

Copy link
Collaborator

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

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

(Just a drive-by, I don’t have an opinion on the performance trade-off.)

@lsm5
Copy link
Member

lsm5 commented Mar 2, 2021

@vrothberg could you perhaps suggest a test to measure this change? And would it make sense to include such a test in CI ? /cc @ashcrow

@vrothberg
Copy link
Member Author

vrothberg commented Mar 2, 2021

@vrothberg could you perhaps suggest a test to measure this change? And would it make sense to include such a test in CI ? /cc @ashcrow

It's rather tough to test such performance-oriented changes. A simple manual test is to force a long copy operation to a registry (e.g., podman push) and in parallel accessing the storage (e.g., podman images). The (expected) result is that second operation is blocked only for a short period of time in contrast to being blocked for the entire copy/push operation as before.

@vrothberg
Copy link
Member Author

toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

Let's wait a bit :^)

@vrothberg vrothberg force-pushed the getblob-optimization branch 2 times, most recently from 1da9d8f to 61d68ad Compare March 2, 2021 14:13
@TomSweeneyRedHat
Copy link
Member

LGTM
assuming rate limits let the test through.

Copy link
Member

@lsm5 lsm5 left a comment

Choose a reason for hiding this comment

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

Change LGTM. I'll try a test with this change and get back if I see anything. Guess we gotta wait anyway for the rate-limiting issue.

When reading blobs (e.g., layers) from the storage, write the data to a
temporary file first and return its file descriptor.

The main goal is to keep the time of the storage being locked as short
as possible.  With this approach we are disk-bound which is generally
faster than the being network bound.

The motivation for this change is the desire to allow for accessing the
storage during pushes.  We have attempted to optimize certain execution
paths in containers/storage but those require the callers to know
whether data will be manipulated or read, which is far from being
trivial.  The daemon-less nature of the storage also requires to write
certain data.

This approach here is entirely transparent to the storage.

Signed-off-by: Valentin Rothberg <rothberg@redhat.com>
@vrothberg vrothberg force-pushed the getblob-optimization branch from 61d68ad to 20f7287 Compare March 2, 2021 16:40
@vrothberg
Copy link
Member Author

Green, and happy.

Copy link
Member

@lsm5 lsm5 left a comment

Choose a reason for hiding this comment

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

Tested locally just now, this is really nice. podman images and other commands don't have to wait for podman push anymore!

LGTM.

@lsm5
Copy link
Member

lsm5 commented Mar 2, 2021

I want to hit merge, but just checking if it's ok to Rebase and merge or do you prefer a merge commit be added?

@vrothberg
Copy link
Member Author

I want to hit merge, but just checking if it's ok to Rebase and merge or do you prefer a merge commit be added?

"Rebase + merge" is the default in c/image. Thanks for reviewing and testing!

@akostadinov
Copy link

How about using a hard link to avoid unnecessary disk writes?

@giuseppe
Copy link
Member

How about using a hard link to avoid unnecessary disk writes?

we'd need to make sure the same file system is used. For that, we could use the new staging directory API that was added to c/storage to address exactly this issue

@mtrmac
Copy link
Collaborator

mtrmac commented Jun 14, 2021

How about using a hard link to avoid unnecessary disk writes?

The data is typically a stream (formed at runtime with tar-split data), not a file that could be linked.

@vrothberg vrothberg deleted the getblob-optimization branch June 17, 2021 07:15
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 this pull request may close these issues.

7 participants