Commit | Line | Data |
---|---|---|
f5db4af4 JB |
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. |