Fix typos and hopefully a list munged by mkdocs.

Mkdocs decided to ignore my list, so I hope adding a newline fixes it.

docs/Understanding_Database_Synchronization.md

@@ -17,9 +17,9 @@ Tuning your database synchronization using the `--db_synchronous_override=0` lau
 
 ## The Secret Sauce
 
-Setting the synchronous to 0 lets the database engine defer writing to disk as long as physically possible.  In the normal operation of your system, files are constantly being partially transfered to disk, even if the OS pretends they have been fully written to disk.  This is called write cache and it is really important to use it or your system's performance would be terrible.  The caveat is that until you have "`synced`" the disk cache, the changes to files are not actually in permanent storage.  One purpose of a normal shutdown of the operating system is to make sure all disk caches have been flushed and synced.  A program can also request that a file it has just written to be flushed, and it will wait until that is done before continuing.
+Setting the synchronous to 0 lets the database engine defer writing to disk as long as physically possible.  In the normal operation of your system, files are constantly being partially transfered to disk, even if the OS pretends they have been fully written to disk.  This is called write cache and it is really important to use it or your system's performance would be terrible.  The caveat is that until you have "`synced`" the disk cache, the changes to files are not actually in permanent storage.  One purpose of a normal shutdown of the operating system is to make sure all disk caches have been flushed and synced.  A program can also request that a file it has just written to be flushed or synced, and it will wait until that is done before continuing.
 
-When not in synchronous 0 mode, the database engine flushes at regular intervals to make sure data has been written.  
+When not in synchronous 0 mode, the database engine syncs at regular intervals to make sure data has been written.  
 - Setting synchronous to 0 is generally safe **if and only if** the system also shuts down normally, allowing any of these pending writes to be flushed.
 - The database can back out of partial changes if hydrus crashes **even if** `synchronous=0`, so your database will not go corrupt from hydrus shutting down abnormally, only from the system shutting down abnormally.
 
@@ -28,11 +28,12 @@ When not in synchronous 0 mode, the database engine flushes at regular intervals
 Programmers are responsible for handling partially written files, but this is tedious for large complex data, so they use a database engine which handles all of this.  The database ensures that any partially written data is reversible to a known state (called a rollback).
 
 An existing file may be in 3 possible states:
-- **Unflushed**: Contents os owned by the program writing the file, but control returns immediately to the program instead of waiting for a full write.  Content can be transitioned from unflushed to flushed using `fflush(FILE)`, `fflush()` is called automatically when a programmer closes a file, or exits the program normally(under most runtimes but not for example in Java).  If the program exits abnormally before data is flushed it will be lost when the program crashes.
-- **Flushed**: Pending write to permenant storage but memory has been transfered to the operating system. Data will not be lost if the calling program crashes, since the OS promises it will "eventually" arrive on disk before returning from `fflush()`. When you "safely shutdown:, you are instructing the OS among other things to sync the flushed files.  If someone decides to read a file before it has been synced the OS will read the contents up until the flush from the flush buffer, and return that instead of what is actually on disk.  If the OS crashes due to error or power failure, files that are flushed but not synced will be lost.
+
+- **Unflushed**: Contents is owned by the program writing the file, but control returns immediately to the program instead of waiting for a full write.  Content can be transitioned from unflushed to flushed using `fflush(FILE)`. `fflush()` is called automatically when a programmer closes a file, or exits the program normally(under most runtimes but not for example in Java).  If the program exits abnormally before data is flushed it will be lost when the program crashes.
+- **Flushed**: Pending write to permenant storage but memory has been transfered to the operating system. Data will not be lost if the calling program crashes, since the OS promises it will "eventually" arrive on disk before returning from `fflush()`. When you "safely shutdown:, you are instructing the OS among other things to sync the flushed files.  If someone decides to read a file before it has been synced the OS will read the contents up until the flush from the flush buffer, and return that instead of what is actually on disk.  If the OS crashes due to error or power failure, data that are flushed but not synced will be lost.
 - **Synced**: Written to permenant storage. A programmer may request that the contents of the file be synced, or it is done gradually over time to free the OS buffers
 
-To ensure the consistency of the database and rollback when needed, the database engine keeps a **journal** of what it is doing.  Each transaction ends in a `flush` followed by a `sync`.  The *flush* ensures that everything written before the flush will not occur before the line that indicats the transaction completed.  The *sync* ensures that the entire contents of the transaction has been written to permenant storage before proceeding. The OS is not obligated to write chunks of the database file in the order it recieves them.  It only guarentees that if you flush everything before the flush happens first, and everything after happens next.
+To ensure the consistency of the database and rollback when needed, the database engine keeps a **journal** of what it is doing.  Each transaction ends in a `flush` followed by a `sync`.  The *flush* ensures that everything written before the flush will occur before the line that indicats the transaction completed.  The *sync* ensures that the entire contents of the transaction has been written to permenant storage before proceeding. The OS is not obligated to write chunks of the database file in the order it recieves them.  It only guarantees that if you flush everything before the flush happens first, and everything after happens next.
 
 The sync is what is controlled by the `synchronous` switch.  Allowing the database to ignore whether sync actually completes is the magic that makes `synchronous=0` so dang fast.