cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

dm-log.rst (2641B)


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