diff --git a/configuration/secondary-storage.md b/configuration/secondary-storage.md
index 1bfbfaff..76c455b5 100644
--- a/configuration/secondary-storage.md
+++ b/configuration/secondary-storage.md
@@ -11,19 +11,15 @@ redirect_from:
 Storing AppVMs on Secondary Drives
 ==================================
 
-Suppose you have a fast but small primary SSD and a large but slow secondary
-HDD.  You want to store a subset of your AppVMs on the HDD.
+Suppose you have a fast but small primary SSD and a large but slow secondary HDD.
+You want to store a subset of your AppVMs on the HDD.
 
 ### R4.0 ###
 
-Qubes 4.0 is more flexible than earlier versions about placing different VMs on
-different disks. For example, you can keep templates on one disk and
-AppVMs on another, without messy symlinks.
+Qubes 4.0 is more flexible than earlier versions about placing different VMs on different disks. 
+For example, you can keep templates on one disk and AppVMs on another, without messy symlinks.
 
-Assuming you have already created a separate [volume group](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/vg_admin#VG_create) and
-[thin pool](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/thinly_provisioned_volume_creation)
-(not thin volume) for your HDD,
-first collect some information in a dom0 terminal:
+Assuming you have already created a separate [volume group](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/vg_admin#VG_create) and [thin pool](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/logical_volume_manager_administration/thinly_provisioned_volume_creation) (not thin volume) for your HDD, first collect some information in a dom0 terminal:
 
     sudo pvs
     sudo lvs
@@ -39,21 +35,17 @@ Now, you can create qubes in that pool:
 
     qvm-create -P pool_name --label red vmname
 
-It isn't possible to directly migrate an existing qube to the new pool, but
-you can clone it there, then remove the old one:
+It isn't possible to directly migrate an existing qube to the new pool, but you can clone it there, then remove the old one:
 
     qvm-clone -P pool_name old_name new_name
     qvm-remove old_name
 
-If that was a template, or other qube referenced elsewhere (NetVM or
-such), you will need to adjust those references manually after moving.
+If that was a template, or other qube referenced elsewhere (NetVM or such), you will need to adjust those references manually after moving.
 For example:
 
     qvm-prefs appvm_based_on_old_name_template template new_name
 
-In theory, you can still use file-based disk images ("file" pool driver),
-but it lacks some features such as you won't be able to do
-backups without shutting down the qube.
+In theory, you can still use file-based disk images ("file" pool driver), but it lacks some features such as you won't be able to do backups without shutting down the qube.
 
 ### R3.2 ###
 
@@ -62,21 +54,17 @@ In dom0:
     mv /var/lib/qubes/appvms/my-new-appvm /path/to/secondary/drive/my-new-appvm
     ln -s /path/to/secondary/drive/my-new-appvm /var/lib/qubes/appvms/
 
-Now, `my-new-appvm` will behave as if it were still stored on the primary SSD
-(except that it will probably be slower, since it's actually stored on the
-secondary HDD).
+Now, `my-new-appvm` will behave as if it were still stored on the primary SSD (except that it will probably be slower, since it's actually stored on the secondary HDD).
 
- * The above procedure does **not** interfere with [Qubes Backup][]. However,
-   attempting to symlink a `private.img` file (rather than the whole AppVM
-   directory) is known to prevent the `private.img` file from being backed up.
-   The same problem may occur if the above procedure is attempted on a
-   [TemplateVM][]. [[1]]
+ * The above procedure does **not** interfere with [Qubes Backup][].
+   However, attempting to symlink a `private.img` file (rather than the whole AppVM directory) is known to prevent the `private.img` file from being backed up.
+   The same problem may occur if the above procedure is attempted on a [TemplateVM][]. [[1]]
 
- * After implementing the above procedure, starting `my-new-appvm` will cause
-   dom0 notifications to occur stating that loop devices have been attached to
-   dom0. This is normal. (No untrusted devices are actually being mounted to
-   dom0.) Do not attempt to detach these disks. (They will automatically be
-   detached when you shut down the AppVM.) [[2]]
+ * After implementing the above procedure, starting `my-new-appvm` will cause dom0 notifications to occur stating that loop devices have been attached to dom0.
+   This is normal. 
+   (No untrusted devices are actually being mounted to dom0.)
+   Do not attempt to detach these disks.
+   (They will automatically be detached when you shut down the AppVM.) [[2]]
 
 [Qubes Backup]: https://www.qubes-os.org/doc/BackupRestore/
 [TemplateVM]: https://www.qubes-os.org/doc/Templates/