1*4882a593Smuzhiyun===================== 2*4882a593SmuzhiyunDevice-Mapper Logging 3*4882a593Smuzhiyun===================== 4*4882a593SmuzhiyunThe device-mapper logging code is used by some of the device-mapper 5*4882a593SmuzhiyunRAID targets to track regions of the disk that are not consistent. 6*4882a593SmuzhiyunA region (or portion of the address space) of the disk may be 7*4882a593Smuzhiyuninconsistent because a RAID stripe is currently being operated on or 8*4882a593Smuzhiyuna machine died while the region was being altered. In the case of 9*4882a593Smuzhiyunmirrors, a region would be considered dirty/inconsistent while you 10*4882a593Smuzhiyunare writing to it because the writes need to be replicated for all 11*4882a593Smuzhiyunthe legs of the mirror and may not reach the legs at the same time. 12*4882a593SmuzhiyunOnce all writes are complete, the region is considered clean again. 13*4882a593Smuzhiyun 14*4882a593SmuzhiyunThere is a generic logging interface that the device-mapper RAID 15*4882a593Smuzhiyunimplementations use to perform logging operations (see 16*4882a593Smuzhiyundm_dirty_log_type in include/linux/dm-dirty-log.h). Various different 17*4882a593Smuzhiyunlogging implementations are available and provide different 18*4882a593Smuzhiyuncapabilities. The list includes: 19*4882a593Smuzhiyun 20*4882a593Smuzhiyun============== ============================================================== 21*4882a593SmuzhiyunType Files 22*4882a593Smuzhiyun============== ============================================================== 23*4882a593Smuzhiyundisk drivers/md/dm-log.c 24*4882a593Smuzhiyuncore drivers/md/dm-log.c 25*4882a593Smuzhiyunuserspace drivers/md/dm-log-userspace* include/linux/dm-log-userspace.h 26*4882a593Smuzhiyun============== ============================================================== 27*4882a593Smuzhiyun 28*4882a593SmuzhiyunThe "disk" log type 29*4882a593Smuzhiyun------------------- 30*4882a593SmuzhiyunThis log implementation commits the log state to disk. This way, the 31*4882a593Smuzhiyunlogging state survives reboots/crashes. 32*4882a593Smuzhiyun 33*4882a593SmuzhiyunThe "core" log type 34*4882a593Smuzhiyun------------------- 35*4882a593SmuzhiyunThis log implementation keeps the log state in memory. The log state 36*4882a593Smuzhiyunwill not survive a reboot or crash, but there may be a small boost in 37*4882a593Smuzhiyunperformance. This method can also be used if no storage device is 38*4882a593Smuzhiyunavailable for storing log state. 39*4882a593Smuzhiyun 40*4882a593SmuzhiyunThe "userspace" log type 41*4882a593Smuzhiyun------------------------ 42*4882a593SmuzhiyunThis log type simply provides a way to export the log API to userspace, 43*4882a593Smuzhiyunso log implementations can be done there. This is done by forwarding most 44*4882a593Smuzhiyunlogging requests to userspace, where a daemon receives and processes the 45*4882a593Smuzhiyunrequest. 46*4882a593Smuzhiyun 47*4882a593SmuzhiyunThe structure used for communication between kernel and userspace are 48*4882a593Smuzhiyunlocated in include/linux/dm-log-userspace.h. Due to the frequency, 49*4882a593Smuzhiyundiversity, and 2-way communication nature of the exchanges between 50*4882a593Smuzhiyunkernel and userspace, 'connector' is used as the interface for 51*4882a593Smuzhiyuncommunication. 52*4882a593Smuzhiyun 53*4882a593SmuzhiyunThere are currently two userspace log implementations that leverage this 54*4882a593Smuzhiyunframework - "clustered-disk" and "clustered-core". These implementations 55*4882a593Smuzhiyunprovide a cluster-coherent log for shared-storage. Device-mapper mirroring 56*4882a593Smuzhiyuncan be used in a shared-storage environment when the cluster log implementations 57*4882a593Smuzhiyunare employed. 58