Fix RAID metadata check

[thirdparty/mdadm.git] / md.4

diff --git a/md.4 b/md.4
index 92b625d32ddc7f936521116f350796dd3291f690..f1b88ee6bb03ee462d2a832b4ab760964539a9fe 100644 (file)
--- a/md.4
+++ b/md.4
@@ -40,7 +40,7 @@ MULTIPATH (a set of different interfaces to the same device),
 and FAULTY (a layer over a single device into which errors can be injected).
 
 .SS MD METADATA
-Each device in an array may have some 
+Each device in an array may have some
 .I metadata
 stored in the device.  This metadata is sometimes called a
 .BR superblock .
@@ -176,7 +176,7 @@ device is rounded down to a multiple of this chunksize.
 A RAID0 array (which has zero redundancy) is also known as a
 striped array.
 A RAID0 array is configured at creation with a
-.B "Chunk Size" 
+.B "Chunk Size"
 which must be a power of two (prior to Linux 2.6.31), and at least 4
 kibibytes.
 
@@ -354,7 +354,7 @@ tab(;);
 | - | - | - | - | - | - |
 C.
 ;
-;Device #1;Device #2;Device #3;Device #4;Device #5
+;Dev #1;Dev #2;Dev #3;Dev #4;Dev #5
 0x00;0;0;1;1;2
 0x01;2;3;3;4;4
 \.\.\.;\.\.\.;\.\.\.;\.\.\.;\.\.\.;\.\.\.
@@ -454,7 +454,7 @@ tab(;);
 | - | - | - | - | - | - |
 C.
 ;
-;Device #1;Device #2;Device #3;Device #4;Device #5
+;Dev #1;Dev #2;Dev #3;Dev #4;Dev #5
 ;
 0x00;0;1;2;3;4;\\ 
 0x01;5;6;7;8;9;> [#]
@@ -564,7 +564,7 @@ tab(;);
 | - | - | - | - | - | - |
 C.
 ;
-;Device #1;Device #2;Device #3;Device #4;Device #5
+;Dev #1;Dev #2;Dev #3;Dev #4;Dev #5
 ;
 0x00;0;1;2;3;4;) AA
 0x01;4;0;1;2;3;) AA~
@@ -846,7 +846,7 @@ intent log if one is present.
 In 2.6.13, intent bitmaps are only supported with RAID1.  Other levels
 with redundancy are supported from 2.6.15.
 
-.SS BAD BLOCK LOG
+.SS BAD BLOCK LIST
 
 From Linux 3.5 each device in an
 .I md
@@ -856,7 +856,7 @@ and the data.
 
 When a block cannot be read and cannot be repaired by writing data
 recovered from other devices, the address of the block is stored in
-the bad block log.  Similarly if an attempt to write a block fails,
+the bad block list.  Similarly if an attempt to write a block fails,
 the address will be recorded as a bad block.  If attempting to record
 the bad block fails, the whole device will be marked faulty.
 
@@ -870,9 +870,29 @@ This allows an array to fail more gracefully - a few blocks on
 different devices can be faulty without taking the whole array out of
 action.
 
-The log is particularly useful when recovering to a spare.  If a few blocks
+The list is particularly useful when recovering to a spare.  If a few blocks
 cannot be read from the other devices, the bulk of the recovery can
-complete and those few bad blocks will be recorded in the bad block log.
+complete and those few bad blocks will be recorded in the bad block list.
+
+.SS RAID456 WRITE JOURNAL
+
+Due to non-atomicity nature of RAID write operations, interruption of
+write operations (system crash, etc.) to RAID456 array can lead to
+inconsistent parity and data loss (so called RAID-5 write hole).
+
+To plug the write hole, from Linux 4.4 (to be confirmed),
+.I md
+supports write ahead journal for RAID456. When the array is created,
+an additional journal device can be added to the array through
+.IR write-journal
+option. The RAID write journal works similar to file system journals.
+Before writing to the data disks, md persists data AND parity of the
+stripe to the journal device. After crashes, md searches the journal
+device for incomplete write operations, and replay them to the data
+disks.
+
+When the journal device fails, the RAID array is forced to run in
+read-only mode.
 
 .SS WRITE-BEHIND
 
@@ -1024,7 +1044,7 @@ number of times MD will service a full-stripe-write before servicing a
 stripe that requires some "prereading".  For fairness this defaults to
 1.  Valid values are 0 to stripe_cache_size.  Setting this to 0
 maximizes sequential-write throughput at the cost of fairness to threads
-doing small or random writes.  
+doing small or random writes.
 
 .SS KERNEL PARAMETERS