The mountinfo parser implemented via `fmt.Sscanf()` is slower than the one
using `strings.Split()` and `strconv.Atoi()`. This rewrite helps to speed it
up to a factor of 8x, here is a result from `go bench`:
> BenchmarkParsingScanf-4 300 22294112 ns/op
> BenchmarkParsingSplit-4 3000 2780703 ns/op
I tried other approaches, such as using `fmt.Sscanf()` for the first
three (integer) fields and `strings.Split()` for the rest, but it slows
things down considerably:
> BenchmarkParsingMixed-4 1000 8827058 ns/op
Note the old code uses `fmt.Sscanf` first, then a linear search for the
'-' field, then a split for the last 3 fields. The new code relies
on a single split.
One other thing is, the new code is more future proof as it skips
extra optional fields before the separator (currently there are none).
I have also added more comments to aid in future development.
Finally, the test data is fixed to not have white space before
the first field.
Based on a similar change in Moby,
https://github.com/moby/moby/pull/36091
[v2: remove no-op break statement to silence staticcheck]
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This allows non-privileged users to use containerd.
If a non root user tried to set a negative oom score adjustment,
it will fail. Containerd should not fail if running rootless.
This is part of a larger track of work integrating containerd
into Cloudfoundry's garden with support for rootless.
[#156343443]
Signed-off-by: Danail Branekov <danailster@gmail.com>
This allows non-privileged users to use containerd. This is part of a
larger track of work integrating containerd into Cloudfoundry's garden
with support for rootless.
[#156343575]
Signed-off-by: Claudia Beresford <cberesford@pivotal.io>
This adds gc.root label to snapshots created with prepare and commit via
the CLI. WIthout this, created snapshots get immediately garbage
collected. There may be a better solution but this seems to be a solid
stop gap.
We may also need to add more functionality around snapshot labeling for
the CLI but current use cases are unclear.
Signed-off-by: Stephen J Day <stevvooe@gmail.com>
This seems to pickup a bunch of *.c files and some other changes which follow
from having included some new packages because of that.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
This renames the license file (so automated tooling can find it, which I care
about) and also pulls in some documentation and comment changes, plus some
functional changes:
PR#33 -- future-proof the algorithm field.
PR#34 -- disallow upper case in hex portion.
No changes appear to be required to containerd code.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Since Go 1.7, context is a standard package, superceding the
"x/net/context". Since Go 1.9, the latter only provides a few type
aliases from the former. Therefore, it makes sense to switch to the
standard package.
This commit was generated by the following script (with a couple of
minor fixups to remove extra changes done by goimports):
#!/bin/bash
if [ $# -ge 1 ]; then
FILES=$*
else
FILES=$(git ls-files \*.go | grep -vF ".pb.go" | grep -v
^vendor/)
fi
for f in $FILES; do
printf .
sed -i -e 's|"golang.org/x/net/context"$|"context"|' $f
goimports -w $f
awk ' /^$/ {e=1; next;}
/[[:space:]]"context"$/ {e=0;}
{if (e) {print ""; e=0}; print;}' < $f > $f.new && \
mv $f.new $f
goimports -w $f
done
echo
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Since Go 1.7, "context" is a standard package, superceding the
"x/net/context". Since Go 1.9, the latter only provides type aliases
from the former. Therefore, it makes sense to switch to the standard
package, and the change is not disruptive in any sense.
This commit deals with a few cases where both packages happened to be
imported by the same source file. A choice between "context" and
"gocontext" was made for each file in order to minimize the patch.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
This version includes "x/net/context" which is fully compatible with
the standard Go "context" package, so the two can be mixed together.
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Deferring the put back of the buffer is not necessary since
it can be done immediately after use, before checking error.
This decreases the amount of the time the buffer is out
of the pool and not in use.
Signed-off-by: Derek McGowan <derek@mcgstyle.net>