Better section name

[ikiwiki.git] / docs / developer / dmmirror / index.mdwn

diff --git a/docs/developer/dmmirror/index.mdwn b/docs/developer/dmmirror/index.mdwn
index 653e4d1..a324164 100644 (file)
--- a/docs/developer/dmmirror/index.mdwn
+++ b/docs/developer/dmmirror/index.mdwn
@@ -36,15 +36,16 @@ volume was out of sync (for faster recovery).
 [[header: WIBM][size][primary/secondary][serial][crc32]]
 
 ##Reading the bitmap
-read two pages
-check crc
-    if any crc is invalid -> use the other (TODO, what if serial is different?)
-    if both crc is invalid -> trouble! full resync
-    both valid -> continue
+- read both bitmaps
+- validate signature (TODO Maybe only on first read?)
+- check crc
+    - if any crc is invalid -> use the other (TODO, what if serial is different?)
+    - if both crc is invalid -> trouble! full resync
+    - if both valid: continue
 
-check serial
-    if one of the copies is outdated, use the other
-    if match we have a valid bitmap
+- check serial
+   - if one of the copies is outdated, use the other
+   - if match we have a valid bitmap
 
 ##Writing the bitmap
 - modify bitmap in memory (bump serial, 1 if overflow)
@@ -53,6 +54,19 @@ check serial
 - write second copy, mark as secondary
 - flushing would be a good idea here! [1]
 
-
+##Writing the data
+- set the dirty flag in the bitmap
+- also set the MODIFIED flag if we run in degraded mode
+- write the actual data
+- remove the dirty bit from the bitmap
 
 [1] does it kill performance?
+
+#RAID1 target design documentation
+
+##Rationale
+First I am going to implement a "raid1" target, which doesnt require a log target as the Linux mirror target. I can make a compatible mirror target in the future using this code/target.
+
+##Implementation details
+###Data structures
+Every mirror leg (from now on: leg) has a structure which contains any information the target may need during operation. Some of these information should be saved to the disk. The structures are contained in a linked list (TAILQ) to allow flexible removal/addition. The O(n) access time shouldn't be a problem as we don't expect a very large number of legs.