| Jonthan Brassow | f5db4af | 2009-06-22 10:12:35 +0100 | [diff] [blame] | 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. |