diff options
Diffstat (limited to 'Documentation/device-mapper')
-rw-r--r-- | Documentation/device-mapper/dm-log.txt | 54 |
1 files changed, 54 insertions, 0 deletions
diff --git a/Documentation/device-mapper/dm-log.txt b/Documentation/device-mapper/dm-log.txt new file mode 100644 index 000000000000..994dd75475a6 --- /dev/null +++ b/Documentation/device-mapper/dm-log.txt | |||
@@ -0,0 +1,54 @@ | |||
1 | Device-Mapper Logging | ||
2 | ===================== | ||
3 | The device-mapper logging code is used by some of the device-mapper | ||
4 | RAID targets to track regions of the disk that are not consistent. | ||
5 | A region (or portion of the address space) of the disk may be | ||
6 | inconsistent because a RAID stripe is currently being operated on or | ||
7 | a machine died while the region was being altered. In the case of | ||
8 | mirrors, a region would be considered dirty/inconsistent while you | ||
9 | are writing to it because the writes need to be replicated for all | ||
10 | the legs of the mirror and may not reach the legs at the same time. | ||
11 | Once all writes are complete, the region is considered clean again. | ||
12 | |||
13 | There is a generic logging interface that the device-mapper RAID | ||
14 | implementations use to perform logging operations (see | ||
15 | dm_dirty_log_type in include/linux/dm-dirty-log.h). Various different | ||
16 | logging implementations are available and provide different | ||
17 | capabilities. The list includes: | ||
18 | |||
19 | Type Files | ||
20 | ==== ===== | ||
21 | disk drivers/md/dm-log.c | ||
22 | core drivers/md/dm-log.c | ||
23 | userspace drivers/md/dm-log-userspace* include/linux/dm-log-userspace.h | ||
24 | |||
25 | The "disk" log type | ||
26 | ------------------- | ||
27 | This log implementation commits the log state to disk. This way, the | ||
28 | logging state survives reboots/crashes. | ||
29 | |||
30 | The "core" log type | ||
31 | ------------------- | ||
32 | This log implementation keeps the log state in memory. The log state | ||
33 | will not survive a reboot or crash, but there may be a small boost in | ||
34 | performance. This method can also be used if no storage device is | ||
35 | available for storing log state. | ||
36 | |||
37 | The "userspace" log type | ||
38 | ------------------------ | ||
39 | This log type simply provides a way to export the log API to userspace, | ||
40 | so log implementations can be done there. This is done by forwarding most | ||
41 | logging requests to userspace, where a daemon receives and processes the | ||
42 | request. | ||
43 | |||
44 | The structure used for communication between kernel and userspace are | ||
45 | located in include/linux/dm-log-userspace.h. Due to the frequency, | ||
46 | diversity, and 2-way communication nature of the exchanges between | ||
47 | kernel and userspace, 'connector' is used as the interface for | ||
48 | communication. | ||
49 | |||
50 | There are currently two userspace log implementations that leverage this | ||
51 | framework - "clustered_disk" and "clustered_core". These implementations | ||
52 | provide a cluster-coherent log for shared-storage. Device-mapper mirroring | ||
53 | can be used in a shared-storage environment when the cluster log implementations | ||
54 | are employed. | ||