Valentin Rothberg

Not to my knowledge. To summarize the above conversation: * Skopeo (or c/image) should print at a given frequency the network IO * When there's no TTY available (e.g., in...

> The progress bars already include (per-layer) speed, so that’s a no-op. I don't think it's enough (see https://github.com/containers/skopeo/issues/658#issuecomment-855733116). Currently, we don't display the exact IO `Copying blob a330b6cecb98 [=====>--------------------------------]...

SGTM @rhatdan @giuseppe @nalind WDYT?

Thanks, @danishprakash! I think it's best to first open a separate issue and discuss how this should look like. Designing inside a PR can be very time consuming, especially for...

@nalind, WDYT? That's roughly related to a PR over at c/image (https://github.com/containers/image/pull/611) which does per-layer locking to avoid redundantly downloading a given blob. This PR isn't merged and I doubt...

Ouch, yes that'll hurt. @rhatdan, any other way to do that? We need some way to clean them up.

@rhatdan sounds complex in shared memory but possible. One thing the afternoon coffee made me think is how could we migrate? Assuming we have fine-grained locking in place. How could...

New versions could take the big lock as readers, this way old versions would block trying to acquire it as writers.

@mheon will know. It's crucial that the locks are non-persistent (in contrast to the containers, image, layer databases etc.). Is that possible with bolt?

@mheon, I'd just put the entire DB on a tmpfs.