Clean up some old setup information for overlayFS

This removes the additional steps for old versions of Docker EE 17.06.
Current versions of Docker EE 17.06 no longer need these additional
steps.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

storage/storagedriver/overlayfs-driver.md

@@ -1,6 +1,6 @@
 ---
 description: Learn how to optimize your use of OverlayFS driver.
-keywords: container, storage, driver, OverlayFS
+keywords: container, storage, driver, OverlayFS, overlay2, overlay
 title: Use the OverlayFS storage driver
 redirect_from:
 - /engine/userguide/storagedriver/overlayfs-driver/
@@ -16,8 +16,7 @@ storage driver as `overlay` or `overlay2`.
 > **Note**: If you use OverlayFS, use the `overlay2` driver rather than the
 > `overlay` driver, because it is more efficient in terms of inode utilization.
 > To use the new driver, you need version 4.0 or higher of the Linux kernel,
-> or RHEL or CentOS using version 3.10.0-514 and above. When using Docker EE 
+> or RHEL or CentOS using version 3.10.0-514 and above.
-> on RHEL or CentOS, you will need to follow some extra steps.
 >
 > For more information about differences between `overlay` vs `overlay2`, check
 > [Docker storage drivers](select-storage-driver.md).
@@ -26,21 +25,15 @@ storage driver as `overlay` or `overlay2`.
 
 OverlayFS is supported if you meet the following prerequisites:
 
-- The `overlay2` driver is supported for Docker EE 17.06.02-ee5 and later and
+- The `overlay2` driver is supported on Docker CE, and Docker EE 17.06.02-ee5 and
-  recommended for Docker CE.
+  up, and is the recommended storage driver.
-
-- The `overlay` driver is allowed but not recommended for Docker CE.
-
 - Version 4.0 or higher of the Linux kernel, or RHEL or CentOS using
-  version 3.10.0-514 of the kernel or higher. Docker EE users using kernels older
+  version 3.10.0-514 of the kernel or higher. If you use an older kernel, you need
-  than 4.0 need to follow some extra steps, outlined below.
+  to use the `overlay` driver, which is not recommended.
-  If you use an older kernel, you need to use the `overlay` driver, which is not
+- The `overlay` and `overlay2` drivers are supported on `xfs` backing filesystems,
-  recommended.
+  but only with `d_type=true` enabled.
 
-- The following backing filesystems are supported:
+    Use `xfs_info` to verify that the `ftype` option is set to `1`. To format an
-  - `ext4` (RHEL 7.1 only)
-  - `xfs` (RHEL 7.2 and higher), but only with `d_type=true` enabled. Use
-    `xfs_info` to verify that the `ftype` option is set to `1`. To format an
     `xfs` filesystem correctly, use the flag `-n ftype=1`.
 
     > **Warning**: Running on XFS without d_type support now causes Docker to
@@ -52,8 +45,8 @@ OverlayFS is supported if you meet the following prerequisites:
 
 - Changing the storage driver makes existing containers and images inaccessible
   on the local system. Use `docker save` to save any images you have built or
-  push them to Docker Hub or a private registry, so that you do not need to
+  push them to Docker Hub or a private registry before changing the storage driver,
-  re-create them later.
+  so that you do not need to re-create them later.
 
 
 ## Configure Docker with the `overlay` or `overlay2` storage driver
@@ -70,6 +63,9 @@ be 4.0 or newer.
 Before following this procedure, you must first meet all the
 [prerequisites](#prerequisites).
 
+The steps below outline how to configure the `overlay2` storage driver. If you
+need to use the legacy `overlay` driver, specify it instead.
+
 
 1. Stop Docker.
 
@@ -96,34 +92,6 @@ Before following this procedure, you must first meet all the
     }
     ```
 
-    > **Note**: RHEL and CentOS users on Docker EE 17.06.02-ee5 and 17.06.02-ee6
-    >
-    > You need to add a second option to the `daemon.json` to disable the check
-    > for version 4.0 or higher of the Linux kernel. Your `daemon.json` should
-    > look like the following. **This is only needed for Docker EE users of RHEL
-    > or CentOS.** Do not attempt to use `overlay2` with kernel versions older
-    > than 3.10.0-514.
-    >
-    > ```json
-    > {
-    >   "storage-driver": "overlay2",
-    >   "storage-opts": [
-    >     "overlay2.override_kernel_check=true"
-    >   ]
-    > }
-    > ```
-    > On kernel versions that support it, Docker EE versions 17.06.02-ee7 and
-    > later enable `overlay2` by default and do not require
-    > `override_kernel_check`.
-
-    If you need to use the legacy `overlay` driver, specify it instead.
-
-    More storage options are available. See all storage options for each storage
-    driver:
-
-    - [Stable](/engine/reference/commandline/dockerd.md#storage-driver-options)
-    - [Edge](/edge/engine/reference/commandline/dockerd.md#storage-driver-options)
-
     Docker does not start if the `daemon.json` file contains badly-formed JSON.
 
 5.  Start Docker.
@@ -132,7 +100,7 @@ Before following this procedure, you must first meet all the
     $ sudo systemctl start docker
     ```
 
-4.  Verify that the daemon is using the `overlay`/`overlay2` storage driver.
+4.  Verify that the daemon is using the `overlay2` storage driver.
     Use the `docker info` command and look for `Storage Driver` and
     `Backing filesystem`.
 
@@ -142,12 +110,14 @@ Before following this procedure, you must first meet all the
     Containers: 0
     Images: 0
     Storage Driver: overlay2
-     Backing Filesystem: extfs
+     Backing Filesystem: xfs
+     Supports d_type: true
+     Native Overlay Diff: true
     <output truncated>
     ```
 
-Docker is now using the `overlay2` storage driver. Docker has automatically
+Docker is now using the `overlay2` storage driver and has automatically
-created the `overlay` mount with the required `lowerdir`, `upperdir`, `merged`,
+created the overlay mount with the required `lowerdir`, `upperdir`, `merged`,
 and `workdir` constructs.
 
 Continue reading for details about how OverlayFS works within your Docker
@@ -165,9 +135,7 @@ process is referred to as a _union mount_. OverlayFS refers to the lower directo
 as `lowerdir` and the upper directory a `upperdir`. The unified view is exposed
 through its own directory called `merged`.
 
-While the `overlay` driver only works with a single lower OverlayFS layer and
+The `overlay2` driver natively supports up to 128 lower OverlayFS layers. This
-hence requires hard links for implementation of multi-layered images, the
-`overlay2` driver natively supports up to 128 lower OverlayFS layers. This
 capability provides better performance for layer-related Docker commands such
 as `docker build` and `docker commit`, and consumes fewer inodes on the backing
 filesystem.
@@ -289,8 +257,10 @@ The `overlay` driver only works with two layers. This means that multi-layered
 images cannot be implemented as multiple OverlayFS layers. Instead, each image
 layer is implemented as its own directory under `/var/lib/docker/overlay`.  Hard
 links are then used as a space-efficient way to reference data shared with lower
-layers. As of Docker 1.10, image layer IDs no longer correspond to directory
+layers. The use of hardlinks causes an excessive use of inodes, which is a known
-names in `/var/lib/docker/`.
+limitation of the legacy `overlay` storage driver, and may require additional
+configuration of the backing filesystem. Refer to the [overlayFS and Docker
+performance](#overlayfs-and-docker-performance) for details.
 
 To create a container, the `overlay` driver combines the directory representing
 the image's top layer plus a new directory for the container. The image's top
@@ -490,7 +460,7 @@ Both `overlay2` and `overlay` drivers are more performant than `aufs` and
   far larger latencies if searching through many AUFS layers. `overlay2` supports
   multiple layers as well, but mitigates any performance hit with caching.
 
-- **Inode limits**. Use of the `overlay` storage driver can cause excessive
+- **Inode limits**. Use of the legacy `overlay` storage driver can cause excessive
   inode consumption. This is especially true in the presence of a large number
   of images and containers on the Docker host. The only way to increase the
   number of inodes available to a filesystem is to reformat it. To avoid running
@@ -509,8 +479,8 @@ The following generic performance best practices also apply to OverlayFS.
   predictable performance for write-heavy workloads. This is because they bypass
   the storage driver and do not incur any of the potential overheads introduced
   by thin provisioning and copy-on-write. Volumes have other benefits, such as
-  allowing you to share data among containers and persisting even when no
+  allowing you to share data among containers and persisting your data even if
-  running container is using them.
+  no running container is using them.
 
 ## Limitations on OverlayFS compatibility
 To summarize the OverlayFS's aspect which is incompatible with other