Fix typos, address feedback

config/daemon/index.md

@@ -122,11 +122,10 @@ By default this directory is:
 You can configure the Docker daemon to use a different directory, using the
 `data-root` configuration option.
 
-Since all the state of a Docker daemon is kept on this directory, make sure
+Since the state of a Docker daemon is kept on this directory, make sure
 you use a dedicated directory for each daemon. If two daemons share the same
-directory, as an example using an NFS share, you might get errors that are
-difficult to troubleshoot.
-
+directory, for example, an NFS share, you are going to experience errors that
+are difficult to troubleshoot.
 
 ## Troubleshoot the daemon
 

storage/index.md

@@ -85,12 +85,14 @@ mounts is to think about where the data lives on the Docker host.
   applications, consider using named volumes instead. You can't use
   Docker CLI commands to directly manage bind mounts.
 
-  > **Warning**: One side effect of using bind mounts, for better or for worse,
+  > Bind mounts allow access to sensitive files
+  >
+  > One side effect of using bind mounts, for better or for worse,
   > is that you can change the **host** filesystem via processes running in a
   > **container**, including creating, modifying, or deleting important system
   > files or directories. This is a powerful ability which can have security
   > implications, including impacting non-Docker processes on the host system.
-  {: .warning }
+  {: .important }
 
 - **[tmpfs mounts](tmpfs.md)**: A `tmpfs` mount is not persisted on disk, either
   on the Docker host or within a container. It can be used by a container during

storage/tmpfs.md

@@ -6,21 +6,20 @@ redirect_from:
 - /engine/admin/volumes/tmpfs/
 ---
 
-[Volumes](volumes.md) and [bind mounts](bind-mounts.md) allow you to share files
-between the host machine and container. This allows you to persist data even
-after the container is stopped.
+[Volumes](volumes.md) and [bind mounts](bind-mounts.md) let you share files
+between the host machine and container so that you can persist data even after
+the container is stopped.
 
 If you're running Docker on Linux, you have a third option: `tmpfs` mounts.
-When you create a container with a `tmpfs` mount, the container has a way to
-create files outside the container's writable layer, just like it happens with
-volumes and bind mounts.
-
-![tmpfs on the Docker host](images/types-of-mounts-tmpfs.png)
+When you create a container with a `tmpfs` mount, the container can create
+files outside the container's writable layer.
 
 As opposed to volumes and bind mounts, a `tmpfs` mount is temporary, and only
 persisted in the host memory. When the container stops, the `tmpfs` mount is
 removed, and files written there won't be persisted.
 
+![tmpfs on the Docker host](images/types-of-mounts-tmpfs.png)
+
 This is useful to temporarily store sensitive files that you don't want to
 persist in either the host or the container writable layer.
 

storage/volumes.md

@@ -362,24 +362,22 @@ $ docker container rm nginxtest
 $ docker volume rm nginx-vol
 ```
 
-## Share data between machines
+## Share data among machines
 
 When building fault-tolerant applications, you might need to configure multiple
 replicas of the same service to have access to the same files.
 
 ![shared storage](images/volumes-shared-storage.svg)
 
-There are multiple ways to achieve this. One way is to develop your
-applications to store files on a cloud object storage system like Amazon S3.
-Another option is to develop your applications to use volumes, but create the
-volume using a driver that supports writing files to an external storage system
-like NFS or Amazon S3.
+There are several ways to achieve this when developing your applications.
+One is to add logic to your application to store files on a cloud object
+storage system like Amazon S3. Another is to create volumes with a driver that
+supports writing files to an external storage system like NFS or Amazon S3.
 
-Volume drivers allow you to abstract to underlying storage system from the
-application logic. As an example if your services are using a volume with
-an NFS driver, you can update the service to use a volume with a different
-driver and start storing data in the cloud, without having to make any changes
-the the application logic.
+Volume drivers allow you to abstract the underlying storage system from the
+application logic. For example, if your services use a volume with an NFS
+driver, you can update the services to use a different driver, as an example to
+store data in the cloud, without changing the application logic.
 
 ## Use a volume driver