DOCS-4667: edits

Signed-off-by: kay <[email protected]>

Author: Sam Kleinman

source/faq/storage.txt

@@ -18,7 +18,7 @@ What is a storage engine?
 ~~~~~~~~~~~~~~~~~~~~~~~~~
 
 A storage engine is the part of a database that is responsible for
-managing how data is stored on disk. Many databases, support multiple
+managing how data is stored on disk. Many databases support multiple
 storage engines, where different engines perform better for specific
 workloads. For example, one storage engine might offer better
 performance for read-heavy workloads, and another might support
@@ -27,18 +27,17 @@ a higher-throughput for write operations.
 What will be the default storage engine going forward?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-MMAPv1 will be the default storage engine in 3.0.  WiredTiger will
-become the default storage engine in a future version of
-MongoDB. You will be able to decide which storage engine is best for
-their application.
+MMAPv1 is the default storage engine in 3.0. With multiple storage
+engines, you will always be able to decide which storage engine is
+best for your application.
 
 Can you mix storage engines in a replica set?
 ---------------------------------------------
 
 Yes. You can have a replica set members that use different storage
 engines.
 
-When designing these milt-storage engine deployments consider the
+When designing these multi-storage engine deployments consider the
 following:
 
 - the oplog on each member may need to be sized differently to account
@@ -55,7 +54,7 @@ Can I upgrade an existing deployment to a WiredTiger?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Yes. You can upgrade an existing deployment to WiredTiger while the
-deployment remains continuously available, by adding replica set
+deployment remains continuously available by adding replica set
 members with the new storage engine and then removing members with the
 legacy storage engine. See the following sections of the
 :doc:`/release-notes/3.0-upgrade` for the complete procedure that you
@@ -68,9 +67,11 @@ can use to upgrade an existing deployment:
 How much compression does WiredTiger provide?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-As much as 50% to 80%. Collection data in WiredTiger use Snappy
-:term:`block compression` by default, and index data use :term:`prefix
-compression` by default.
+The ratio of compressed data to uncompressed data depends on your data
+and the compression library used. Collection data in WiredTiger use
+Snappy :term:`block compression` by default, although ``zlib``
+compression is also optionally available. Index data use
+:term:`prefix compression` by default.
 
 MMAP Storage Engine
 -------------------
@@ -185,10 +186,10 @@ something like this in the log:
    Thu Aug 11 13:06:19 [FileAllocator] error failed to allocate new file: dbms/test.13 size: 2146435072 errno:28 No space left on device
    Thu Aug 11 13:06:19 [FileAllocator]     will try again in 10 seconds
 
-The server remains in this state forever, blocking all writes including
-deletes. However, reads still work. To delete some data and compact,
-using the :dbcommand:`compact` command, you must restart the server
-first.
+The server remains in this state forever, blocking all writes
+including deletes. However, reads still work. With MMAPv1 you can
+delete some data and compact, using the :dbcommand:`compact` command;
+however, you must restart the server first.
 
 If your server runs out of disk space for journal files, the server
 process will exit. By default, :program:`mongod` creates journal files
@@ -202,6 +203,61 @@ filesystem mount or a symlink.
    will not be able to use a file system snapshot tool to capture a
    valid snapshot of your data files and journal files.
 
+.. _faq-working-set:
+
+What is the working set?
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Working set represents the total body of data that the application
+uses in the course of normal operation. Often this is a subset of the
+total data size, but the specific size of the working set depends on
+actual moment-to-moment use of the database.
+
+If you run a query that requires MongoDB to scan every document in a
+collection, the working set will expand to include every
+document. Depending on physical memory size, this may cause documents
+in the working set to "page out," or to be removed from physical memory by
+the operating system. The next time MongoDB needs to access these
+documents, MongoDB may incur a hard page fault.
+
+For best performance, the majority of your *active* set should fit in
+RAM.
+
+.. _faq-storage-page-faults:
+
+What are page faults?
+~~~~~~~~~~~~~~~~~~~~~
+
+.. include:: /includes/fact-page-fault.rst
+
+If there is free memory, then the operating system can find the page
+on disk and load it to memory directly. However, if there is no free
+memory, the operating system must:
+
+- find a page in memory that is stale or no longer needed, and write
+  the page to disk.
+
+- read the requested page from disk and load it into memory.
+
+This process, on an active system, can take a long time,
+particularly in comparison to reading a page that is already in
+memory.
+
+See :ref:`administration-monitoring-page-faults` for more information.
+
+What is the difference between soft and hard page faults?
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+:term:`Page faults <page fault>` occur when MongoDB, with the MMAP
+storage engine, needs access to data that isn't currently in active
+memory. A "hard" page fault refers to situations when MongoDB must
+access a disk to access the data. A "soft" page fault, by contrast,
+merely moves memory pages from one list to another, such as from an
+operating system file cache. In production, MongoDB will rarely
+encounter soft page faults.
+
+See :ref:`administration-monitoring-page-faults` for more information.
+
 Data Storage Diagnostics
 ------------------------
 
@@ -249,68 +305,7 @@ collection:
 What tools can I use to investigate storage use in MongoDB?
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-The :method:`db.stats()` method in the :program:`mongo` shell,
+The :method:`db.stats()` method in the :program:`mongo` shell
 returns the current state of the "active" database. The
-:doc:`dbStats command </reference/command/dbStats>` document describes
+:dbcommand:`dbStats` document describes
 the fields in the :method:`db.stats()` output.
-
-Page Faults
------------
-
-.. _faq-working-set:
-
-What is the working set?
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-Working set represents the total body of data that the application
-uses in the course of normal operation. Often this is a subset of the
-total data size, but the specific size of the working set depends on
-actual moment-to-moment use of the database.
-
-If you run a query that requires MongoDB to scan every document in a
-collection, the working set will expand to include every
-document. Depending on physical memory size, this may cause documents
-in the working set to "page out," or to be removed from physical memory by
-the operating system. The next time MongoDB needs to access these
-documents, MongoDB may incur a hard page fault.
-
-If you run a query that requires MongoDB to scan every
-:term:`document` in a collection, the working set includes every
-active document in memory.
-
-For best performance, the majority of your *active* set should fit in
-RAM.
-
-.. _faq-storage-page-faults:
-
-What are page faults?
-~~~~~~~~~~~~~~~~~~~~~
-
-.. include:: /includes/fact-page-fault.rst
-
-If there is free memory, then the operating system can find the page
-on disk and load it to memory directly. However, if there is no free
-memory, the operating system must:
-
-- find a page in memory that is stale or no longer needed, and write
-  the page to disk.
-
-- read the requested page from disk and load it into memory.
-
-This process, particularly on an active system can take a long time,
-particularly in comparison to reading a page that is already in
-memory.
-
-See :ref:`administration-monitoring-page-faults` for more information.
-
-What is the difference between soft and hard page faults?
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-:term:`Page faults <page fault>` occur when MongoDB needs access to
-data that isn't currently in active memory. A "hard" page fault
-refers to situations when MongoDB must access a disk to access the
-data. A "soft" page fault, by contrast, merely moves memory pages from
-one list to another, such as from an operating system file
-cache. In production, MongoDB will rarely encounter soft page faults.
-
-See :ref:`administration-monitoring-page-faults` for more information.

source/includes/fact-page-fault.rst

@@ -1,4 +1,5 @@
-Page faults can occur as MongoDB reads from or writes data to parts of its
-data files that are not currently located in physical memory. In contrast,
-operating system page faults happen when physical memory is exhausted and
-pages of physical memory are swapped to disk.
+Page faults can occur as MongoDB, with the MMAP storage engine, reads
+from or writes data to parts of its data files that are not currently
+located in physical memory. In contrast, operating system page faults
+happen when physical memory is exhausted and pages of physical memory
+are swapped to disk.