Merge pull request #24794 from Nedunchezhiyan-M/fix/style-meta-commentary-engine

engine: remove Vale-flagged meta-commentary in storage driver docs

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.

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.