Accueil Explorer Aide
Connexion
phreedom2600net
/
linux-libre
Suivre 2
Voter 0
Fork 0
Fichiers Tickets 0 Pull Requests 0 Wiki
Branche: master
Branches Tags
linux-libre
/
Documentation
/
device-mapper
/
dm-log.txt

dm-log.txt 2.3 KB
Lien permanent Historique Raw

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455 
  1. Device-Mapper Logging
    2. 

  2. =====================
    3. 

  3. The device-mapper logging code is used by some of the device-mapper
    4. 

  4. RAID targets to track regions of the disk that are not consistent.
    5. 

  5. A region (or portion of the address space) of the disk may be
    6. 

  6. inconsistent because a RAID stripe is currently being operated on or
    7. 

  7. a machine died while the region was being altered.  In the case of
    8. 

  8. mirrors, a region would be considered dirty/inconsistent while you
    9. 

  9. are writing to it because the writes need to be replicated for all
    10. 

  10. the legs of the mirror and may not reach the legs at the same time.
    11. 

  11. Once all writes are complete, the region is considered clean again.
    12. 

  12. 

  13. There is a generic logging interface that the device-mapper RAID
    14. 

  14. implementations use to perform logging operations (see
    15. 

  15. dm_dirty_log_type in include/linux/dm-dirty-log.h).  Various different
    16. 

  16. logging implementations are available and provide different
    17. 

  17. capabilities.  The list includes:
    18. 

  18. 

  19. Type		Files
    20. 

  20. ====		=====
    21. 

  21. disk		drivers/md/dm-log.c
    22. 

  22. core		drivers/md/dm-log.c
    23. 

  23. userspace	drivers/md/dm-log-userspace* include/linux/dm-log-userspace.h
    24. 

  24. 

  25. The "disk" log type
    26. 

  26. -------------------
    27. 

  27. This log implementation commits the log state to disk.  This way, the
    28. 

  28. logging state survives reboots/crashes.
    29. 

  29. 

  30. The "core" log type
    31. 

  31. -------------------
    32. 

  32. This log implementation keeps the log state in memory.  The log state
    33. 

  33. will not survive a reboot or crash, but there may be a small boost in
    34. 

  34. performance.  This method can also be used if no storage device is
    35. 

  35. available for storing log state.
    36. 

  36. 

  37. The "userspace" log type
    38. 

  38. ------------------------
    39. 

  39. This log type simply provides a way to export the log API to userspace,
    40. 

  40. so log implementations can be done there.  This is done by forwarding most
    41. 

  41. logging requests to userspace, where a daemon receives and processes the
    42. 

  42. request.
    43. 

  43. 

  44. The structure used for communication between kernel and userspace are
    45. 

  45. located in include/linux/dm-log-userspace.h.  Due to the frequency,
    46. 

  46. diversity, and 2-way communication nature of the exchanges between
    47. 

  47. kernel and userspace, 'connector' is used as the interface for
    48. 

  48. communication.
    49. 

  49. 

  50. There are currently two userspace log implementations that leverage this
    51. 

  51. framework - "clustered-disk" and "clustered-core".  These implementations
    52. 

  52. provide a cluster-coherent log for shared-storage.  Device-mapper mirroring
    53. 

  53. can be used in a shared-storage environment when the cluster log implementations
    54. 

  54. are employed.
    55. 

  55.