Bad block log

1 files changed, 28 insertions, 0 deletions

diff --git a/md.4 b/md.4
index 99faad1a..fa870655 100644
--- a/md.4
+++ b/md.4
@@ -551,6 +551,34 @@ 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
+
+From Linux 3.5 each device in an
+.I md
+array can store a list of known-bad-blocks.  This list is 4K in size
+and usually positioned at the end of the space between the superblock
+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 address will be recorded as a bad block.  If attempting to record
+the bad block fails, the whole device will be marked faulty.
+
+Attempting to read from a known bad block will cause a read error.
+Attempting to write to a known bad block will be ignored if any write
+errors have been reported by the device.  If there have been no write
+errors then the data will be written to the known bad block and if
+that succeeds, the address will be removed from the list.
+
+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
+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.
+
 .SS WRITE-BEHIND
 
 From Linux 2.6.14,