When the user is not using the full has to retrieve a container it's
possible that we find conflicts with the ids of other containers.
At the moment it's just failing saying that it can not find a container,
but it doesn't say why. Adding a small log saying that duplicates where
found is going to help the user.
Closes#8098
Signed-off-by: Alex Gonzalez <agonzalezro@gmail.com>
This makes sure that we don't buffer in memory and that we also flush
stdin from diff as well as untar.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
Conflicts:
pkg/chrootarchive/diff.go
This makes sure that we don't buffer in memory and that we also flush
stdin from diff as well as untar.
Signed-off-by: Michael Crosby <crosbymichael@gmail.com>
If two interrupts were fired really quickly interruptCount could have been incremented twice before the LoadUint32 making cleanup not being called at all.
Signed-off-by: Erik Dubbelboer <erik@dubbelboer.com>
Another update to TarSum tests, this patch fixes an issue where
the benchmarks were generating archives incorrectly by not closing
the tarWriter.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
With 32ba6ab from #9261, TempArchive now closes the underlying file and
cleans it up as soon as the file's contents have been read. When pushing
an image, PushImageLayerRegistry attempts to call Close() on the layer,
which is a TempArchive that has already been closed. In this situation,
Close() returns an "invalid argument" error.
Add a Close method to TempArchive that does a no-op if the underlying
file has already been closed.
Signed-off-by: Andy Goldstein <agoldste@redhat.com>
These two cases did not actually read the same content with each iteration
of the benchmark. After the first read, the buffer was consumed. This patch
corrects this by using a bytes.Reader and seeking to the beginning of the
buffer at the beginning of each iteration.
Unfortunately, this benchmark was not actually as fast as we believed. But
the new results do bring its results closer to those of the other benchmarks.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Currently devicemapper CreateDevice and CreateSnapDevice keep on retrying
device creation till a suitable device id is found.
With new transaction mechanism we need to store device id in transaction
before it has been created.
So change the logic in such a way that caller decides the devices Id to
use. If that device Id is not available, caller bumps up the device Id
and retries.
That way caller can update transaciton too when it tries a new Id. Transaction
related patches will come later in the series.
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
I noticed that 3 of the tarsum test cases had expected a tarsum with
a sha256 hash of
e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
As I've been working with sha256 quite a bit lately, it struck me that
this is the initial digest value for sha256, which means that no data
was processed. However, these tests *do* process data. It turns out that
there was a bug in the test handling code which did not wait for tarsum
to end completely. This patch corrects these test cases.
I'm unaware of anywhere else in the code base where this would be an issue,
though we definitily need to look out in the future to ensure we are
completing tarsum reads (waiting for EOF).
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Current implementation is comingling things that ought not be together.
There are _some_ similarities between parsing for the different proto
types, but they are more different than alike, making the code extremely
difficult to reason about.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This reverts commit 967a42f116d23051c862a3b4983925de2016f83c.
Signed-off-by: Tatsushi Inagaki <e29253@jp.ibm.com>
Roll back the change to fix the parameter of HumanSize from int64 to float64
