github.com/containerd/Containerd@v1.4.13/design/mounts.md (about)

     1  # Mounts
     2  
     3  Mounts are the main interaction mechanism in containerd. Container systems of
     4  the past typically end up having several disparate components independently
     5  perform mounts, resulting in complex lifecycle management and buggy behavior
     6  when coordinating large mount stacks.
     7  
     8  In containerd, we intend to keep mount syscalls isolated to the container
     9  runtime component, opting to have various components produce a serialized
    10  representation of the mount. This ensures that the mounts are performed as a
    11  unit and unmounted as a unit.
    12  
    13  From an architecture perspective, components produce mounts and runtime
    14  executors consume them.
    15  
    16  More imaginative use cases include the ability to virtualize a series of mounts
    17  from various components without ever having to create a runtime. This will aid
    18  in testing and implementation of satellite components.
    19  
    20  ## Structure
    21  
    22  The `Mount` type follows the structure of the historic mount syscall:
    23  
    24  | Field | Type | Description |
    25  |-------|----|-------------|
    26  | Type | `string` | Specific type of the mount, typically operating system specific |
    27  | Target | `string` | Intended filesystem path for the mount destination. |
    28  | Source | `string` | The object which originates the mount, typically a device or another filesystem path. |
    29  | Options | `[]string` | Zero or more options to apply with the mount, possibly `=`-separated key value pairs. | 
    30  
    31  We may want to further parameterize this to support mounts with various
    32  helpers, such as `mount.fuse`, but this is out of scope, for now.