3 files changed, 52 insertions, 5 deletions

diff --git a/Documentation/device-mapper/dm-raid.txt b/Documentation/device-mapper/dm-raid.txt
index 946c73342cde..1c1844957166 100644
--- a/Documentation/device-mapper/dm-raid.txt
+++ b/Documentation/device-mapper/dm-raid.txt
@@ -27,6 +27,10 @@ The target is named "raid" and it accepts the following parameters:
                 - rotating parity N (right-to-left) with data restart
   raid6_nc      RAID6 N continue
                 - rotating parity N (right-to-left) with data continuation
+  raid10        Various RAID10 inspired algorithms chosen by additional params
+                - RAID10: Striped Mirrors (aka 'Striping on top of mirrors')
+                - RAID1E: Integrated Adjacent Stripe Mirroring
+                -  and other similar RAID10 variants
 
   Reference: Chapter 4 of
   http://www.snia.org/sites/default/files/SNIA_DDF_Technical_Position_v2.0.pdf
@@ -59,6 +63,28 @@ The target is named "raid" and it accepts the following parameters:
                 logical size of the array.  The bitmap records the device
                 synchronisation state for each region.
 
+        [raid10_copies   <# copies>]
+        [raid10_format   near]
+                These two options are used to alter the default layout of
+                a RAID10 configuration.  The number of copies is can be
+                specified, but the default is 2.  There are other variations
+                to how the copies are laid down - the default and only current
+                option is "near".  Near copies are what most people think of
+                with respect to mirroring.  If these options are left
+                unspecified, or 'raid10_copies 2' and/or 'raid10_format near'
+                are given, then the layouts for 2, 3 and 4 devices are:
+                2 drives         3 drives          4 drives
+                --------         ----------        --------------
+                A1  A1           A1  A1  A2        A1  A1  A2  A2
+                A2  A2           A2  A3  A3        A3  A3  A4  A4
+                A3  A3           A4  A4  A5        A5  A5  A6  A6
+                A4  A4           A5  A6  A6        A7  A7  A8  A8
+                ..  ..           ..  ..  ..        ..  ..  ..  ..
+                The 2-device layout is equivalent 2-way RAID1.  The 4-device
+                layout is what a traditional RAID10 would look like.  The
+                3-device layout is what might be called a 'RAID1E - Integrated
+                Adjacent Stripe Mirroring'.
+
 <#raid_devs>: The number of devices composing the array.
         Each device consists of two entries.  The first is the device
         containing the metadata (if any); the second is the one containing the
diff --git a/Documentation/device-mapper/striped.txt b/Documentation/device-mapper/striped.txt
index f34d3236b9da..45f3b91ea4c3 100644
--- a/Documentation/device-mapper/striped.txt
+++ b/Documentation/device-mapper/striped.txt
@@ -9,15 +9,14 @@ devices in parallel.
 
 Parameters: <num devs> <chunk size> [<dev path> <offset>]+
     <num devs>: Number of underlying devices.
-    <chunk size>: Size of each chunk of data. Must be a power-of-2 and at
-                  least as large as the system's PAGE_SIZE.
+    <chunk size>: Size of each chunk of data. Must be at least as
+                  large as the system's PAGE_SIZE.
     <dev path>: Full pathname to the underlying block-device, or a
                 "major:minor" device-number.
     <offset>: Starting sector within the device.
 
 One or more underlying devices can be specified. The striped device size must
-be a multiple of the chunk size and a multiple of the number of underlying
-devices.
+be a multiple of the chunk size multiplied by the number of underlying devices.
 
 
 Example scripts
diff --git a/Documentation/device-mapper/thin-provisioning.txt b/Documentation/device-mapper/thin-provisioning.txt
index f5cfc62b7ad3..30b8b83bd333 100644
--- a/Documentation/device-mapper/thin-provisioning.txt
+++ b/Documentation/device-mapper/thin-provisioning.txt
@@ -231,6 +231,9 @@ i) Constructor
       no_discard_passdown: Don't pass discards down to the underlying
                            data device, but just remove the mapping.
 
+      read_only: Don't allow any changes to be made to the pool
+                 metadata.
+
     Data block size must be between 64KB (128 sectors) and 1GB
     (2097152 sectors) inclusive.
 
@@ -239,7 +242,7 @@ ii) Status
 
     <transaction id> <used metadata blocks>/<total metadata blocks>
     <used data blocks>/<total data blocks> <held metadata root>
-
+    [no_]discard_passdown ro|rw
 
     transaction id:
         A 64-bit number used by userspace to help synchronise with metadata
@@ -257,6 +260,21 @@ ii) Status
         held root.  This feature is not yet implemented so '-' is
         always returned.
 
+    discard_passdown|no_discard_passdown
+        Whether or not discards are actually being passed down to the
+        underlying device.  When this is enabled when loading the table,
+        it can get disabled if the underlying device doesn't support it.
+
+    ro|rw
+        If the pool encounters certain types of device failures it will
+        drop into a read-only metadata mode in which no changes to
+        the pool metadata (like allocating new blocks) are permitted.
+
+        In serious cases where even a read-only mode is deemed unsafe
+        no further I/O will be permitted and the status will just
+        contain the string 'Fail'.  The userspace recovery tools
+        should then be used.
+
 iii) Messages
 
     create_thin <dev id>
@@ -329,3 +347,7 @@ regain some space then send the 'trim' message to the pool.
 ii) Status
 
      <nr mapped sectors> <highest mapped sector>
+
+        If the pool has encountered device errors and failed, the status
+        will just contain the string 'Fail'.  The userspace recovery
+        tools should then be used.