diff --git a/content/manuals/engine/storage/drivers/_index.md b/content/manuals/engine/storage/drivers/_index.md index 9c407581d0..627ee6202e 100644 --- a/content/manuals/engine/storage/drivers/_index.md +++ b/content/manuals/engine/storage/drivers/_index.md @@ -19,7 +19,7 @@ aliases: > won't reflect how your system stores images. For operational guidance, see > [containerd image store](../containerd.md). -To use storage drivers effectively, it's important to know how Docker builds and +To use storage drivers effectively, you need to know how Docker builds and stores images, and how these images are used by containers. You can use this information to make informed choices about the best way to persist data from your applications and avoid performance problems along the way. diff --git a/content/manuals/engine/storage/drivers/aufs-driver.md b/content/manuals/engine/storage/drivers/aufs-driver.md index b966b5530a..2761989cb9 100644 --- a/content/manuals/engine/storage/drivers/aufs-driver.md +++ b/content/manuals/engine/storage/drivers/aufs-driver.md @@ -1,6 +1,6 @@ --- description: Learn how to optimize your use of AUFS driver. -keywords: 'container, storage, driver, AUFS ' +keywords: "container, storage, driver, AUFS " title: AUFS storage driver sitemap: false aliases: @@ -14,7 +14,7 @@ aliases: > before upgrading to Docker Engine v24.0. Read the [Docker storage drivers](select-storage-driver.md) > page for supported storage drivers. -AUFS is a *union filesystem*. The `aufs` storage driver was previously the default +AUFS is a _union filesystem_. The `aufs` storage driver was previously the default storage driver used for managing images and layers on Docker for Ubuntu, and for Debian versions prior to Stretch. If your Linux kernel is version 4.0 or higher, and you use Docker Engine - Community, consider using the newer @@ -26,7 +26,7 @@ potential performance advantages over the `aufs` storage driver. - For Docker Engine - Community, AUFS is supported on Ubuntu, and on Debian versions prior to Stretch. - If you use Ubuntu, you need to add the AUFS module to the kernel. If you do - not install these packages, you need to use `overlay2`. + not install these packages, you need to use `overlay2`. - AUFS cannot use the following backing filesystems: `aufs`, `btrfs`, or `ecryptfs`. This means that the filesystem which contains `/var/lib/docker/aufs` cannot be one of these filesystem types. @@ -66,7 +66,7 @@ storage driver is configured, Docker uses it by default. ## How the `aufs` storage driver works -AUFS is a *union filesystem*, which means that it layers multiple directories on +AUFS is a _union filesystem_, which means that it layers multiple directories on a single Linux host and presents them as a single directory. These directories are called _branches_ in AUFS terminology, and _layers_ in Docker terminology. @@ -74,7 +74,7 @@ The unification process is referred to as a _union mount_. The diagram below shows a Docker container based on the `ubuntu:latest` image. -![Layers of an Ubuntu container](images/aufs_layers.webp) +![Layers of an Ubuntu container](images/aufs_layers.webp) Each image layer, and the container layer, are represented on the Docker host as subdirectories within `/var/lib/docker/`. The union mount provides the unified @@ -126,7 +126,7 @@ If a container is running, the contents of `/var/lib/docker/aufs/` change in the following ways: - `diff/`: Differences introduced in the writable container layer, such as new - or modified files. + or modified files. - `layers/`: Metadata about the writable container layer's parent layers. - `mnt/`: A mount point for each running container's unified filesystem, exactly as it appears from within the container. @@ -160,7 +160,7 @@ Consider some scenarios where files in a container are modified. - **Writing to a file for the first time**: The first time a container writes to an existing file, that file does not exist in the container (`upperdir`). - The `aufs` driver performs a *copy_up* operation to copy the file from the + The `aufs` driver performs a _copy_up_ operation to copy the file from the image layer where it exists to the writable container layer. The container then writes the changes to the new copy of the file in the container layer. @@ -169,13 +169,12 @@ Consider some scenarios where files in a container are modified. very large and only a small part of it is being modified. This can have a noticeable impact on container write performance. AUFS can suffer noticeable latencies when searching for files in images with many layers. - However, it is worth noting that the copy_up operation only occurs the first - time a given file is written to. Subsequent writes to the same file operate - against the copy of the file already copied up to the container. + However, the copy_up operation only occurs the first time a given file is + written to. Subsequent writes to the same file operate against the copy of + the file already copied up to the container. - **Deleting files and directories**: - - - When a _file_ is deleted within a container, a *whiteout* file is created + - When a _file_ is deleted within a container, a _whiteout_ file is created in the container layer. The version of the file in the image layer is not deleted (because the image layers are read-only). However, the whiteout file prevents it from being available to the container.