Fix some typos
Signed-off-by: Qiang Huang <h.huangqiang@huawei.com>
This commit is contained in:
parent
22772224e6
commit
3b8eee7522
5 changed files with 8 additions and 8 deletions
|
@ -25,7 +25,7 @@ type ContentWriter struct {
|
|||
// Write p to the transaction.
|
||||
//
|
||||
// Note that writes are unbuffered to the backing file. When writing, it is
|
||||
// recommended to wrap in a bufio.Writer or, preferrably, use io.CopyBuffer.
|
||||
// recommended to wrap in a bufio.Writer or, preferably, use io.CopyBuffer.
|
||||
func (cw *ContentWriter) Write(p []byte) (n int, err error) {
|
||||
n, err = cw.fp.Write(p)
|
||||
cw.digester.Hash().Write(p[:n])
|
||||
|
|
|
@ -1,11 +1,11 @@
|
|||
# Mounts
|
||||
|
||||
Mounts are the main interaction mechansim in containerD. Container systems of
|
||||
Mounts are the main interaction mechanism in containerd. Container systems of
|
||||
the past typically end up having several disparate components independently
|
||||
perform mounts, resulting in complex lifecycle management and buggy behavior
|
||||
when coordinating large mount stacks.
|
||||
|
||||
In containerD, we intend to keep mount syscalls isolated to the container
|
||||
In containerd, we intend to keep mount syscalls isolated to the container
|
||||
runtime component, opting to have various components produce a serialized
|
||||
representation of the mount. This ensures that the mounts are performed as a
|
||||
unit and unmounted as a unit.
|
||||
|
|
|
@ -45,7 +45,7 @@ interface.
|
|||
## Architecture
|
||||
|
||||
The _Snapshot Manager_ provides an API for allocating, snapshotting and mounting
|
||||
abstract, layer-based filesytems. The model works by building up sets of
|
||||
abstract, layer-based filesystems. The model works by building up sets of
|
||||
directories with parent-child relationships, known as _Snapshots_.
|
||||
|
||||
Every snapshot is represented by an opaque `diff` directory, which acts as a
|
||||
|
|
|
@ -4,7 +4,7 @@ import "context"
|
|||
|
||||
type topicKey struct{}
|
||||
|
||||
// WithTopic returns a context with a new topic set, such that events emmited
|
||||
// WithTopic returns a context with a new topic set, such that events emitted
|
||||
// from the resulting context will be marked with the topic.
|
||||
//
|
||||
// A topic groups events by the target module they operate on. This is
|
||||
|
@ -13,7 +13,7 @@ type topicKey struct{}
|
|||
// When compacting the journal, we can replace all former log entries with a
|
||||
// summary data structure that will result in the same state.
|
||||
//
|
||||
// By providing a compaction mechansim by topic, we can prune down to a data
|
||||
// By providing a compaction mechanism by topic, we can prune down to a data
|
||||
// structure oriented towards a single topic, leaving unrelated messages alone.
|
||||
func WithTopic(ctx context.Context, topic string) context.Context {
|
||||
return context.WithValue(ctx, topicKey{}, topic)
|
||||
|
|
|
@ -11,7 +11,7 @@ import (
|
|||
)
|
||||
|
||||
// Manager provides an API for allocating, snapshotting and mounting
|
||||
// abstract, layer-based filesytems. The model works by building up sets of
|
||||
// abstract, layer-based filesystems. The model works by building up sets of
|
||||
// directories with parent-child relationships.
|
||||
//
|
||||
// These differ from the concept of the graphdriver in that the
|
||||
|
@ -203,7 +203,7 @@ func (lm *Manager) Prepare(dst, parent string) ([]containerd.Mount, error) {
|
|||
}, nil
|
||||
}
|
||||
|
||||
// View behaves identically to Prepare except the result may not be commited
|
||||
// View behaves identically to Prepare except the result may not be committed
|
||||
// back to the snappshot manager.
|
||||
//
|
||||
// Whether or not these are readonly mounts is implementation specific, but the
|
||||
|
|
Loading…
Reference in a new issue