1# Mounts 2 3Mounts are the main interaction mechanism in containerd. Container systems of 4the past typically end up having several disparate components independently 5perform mounts, resulting in complex lifecycle management and buggy behavior 6when coordinating large mount stacks. 7 8In containerd, we intend to keep mount syscalls isolated to the container 9runtime component, opting to have various components produce a serialized 10representation of the mount. This ensures that the mounts are performed as a 11unit and unmounted as a unit. 12 13From an architecture perspective, components produce mounts and runtime 14executors consume them. 15 16More imaginative use cases include the ability to virtualize a series of mounts 17from various components without ever having to create a runtime. This will aid 18in testing and implementation of satellite components. 19 20## Structure 21 22The `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 31We may want to further parameterize this to support mounts with various 32helpers, such as `mount.fuse`, but this is out of scope, for now. 33