fix some typos

Signed-off-by: Aaron.L.Xu <likexu@harmonycloud.cn>

archive/tar.go

@@ -386,7 +386,7 @@ func (cw *changeWriter) Close() error {
 }
 
 func createTarFile(ctx context.Context, path, extractDir string, hdr *tar.Header, reader io.Reader) error {
-	// hdr.Mode is in linux format, which we can use for sycalls,
+	// hdr.Mode is in linux format, which we can use for syscalls,
 	// but for os.Foo() calls we need the mode converted to os.FileMode,
 	// so use hdrInfo.Mode() (they differ for e.g. setuid bits)
 	hdrInfo := hdr.FileInfo()

design/data-flow.md

@@ -5,7 +5,7 @@ images, hiding many details and complexity. This document intends to shed light
 on that complexity and detail how a "pull" operation will look from the
 perspective of a containerd user. We use the _bundle_ as the target object in
 this workflow, and walk back from there to describe the full process. In this
-context, we describe bothing pulling an image and creating a bundle from that
+context, we describe both pulling an image and creating a bundle from that
 image.
 
 With containerd, we redefine the "pull" to comprise the same set of steps

design/lifecycle.md

@@ -11,4 +11,4 @@ The daemon provides an API to manage multiple containers.  It can handle locking
 
 Each container has its own shim that acts as the direct parent of the container's processes.  The shim is responsible for keeping the IO and/or pty master of the container open, writing the container's exit status for containerd, and reaping the container's processes when they exit.  Since the shim owns the container's pty master, it provides an API for resizing.
 
-Overall, a container's lifecycle is not tied to the containerd daemon.  The daemon is a management API for multiple container whoms lifecycle is tied to one shim per container.
+Overall, a container's lifecycle is not tied to the containerd daemon.  The daemon is a management API for multiple container whose lifecycle is tied to one shim per container.

fs/diff_test.go

@@ -161,7 +161,7 @@ func testDiffWithBase(base, diff fstest.Applier, expected []testChange) error {
 	defer os.RemoveAll(t2)
 
 	if err := base.Apply(t1); err != nil {
-		return errors.Wrap(err, "failed to apply base filesytem")
+		return errors.Wrap(err, "failed to apply base filesystem")
 	}
 
 	if err := CopyDir(t2, t1); err != nil {

reports/2017-02-10.md

@@ -43,7 +43,7 @@ The content and storage subsystems would produce bundles and the execution subsy
 However, with a bundle being on the filesystem, having this concept does not work as smoothly on Windows
 as it would for Unix platforms.
 
-So the major design change is that bundles will be an implemenation detail of the runtime and not a core
+So the major design change is that bundles will be an implementation detail of the runtime and not a core
 part of the API.  You will no longer pass the bundle path to containerd, it will manage bundles internally
 and the root filesystem mounts along with the spec, passed via the `Any` type, will be API fields for the 
 create request of a container.