TEXT   34

GFS2 uevents

Guest on 23rd November 2022 01:53:08 AM

  1.                               uevents and GFS2
  2.                              ==================
  3.  
  4. During the lifetime of a GFS2 mount, a number of uevents are generated.
  5. This document explains what the events are and what they are used
  6. for (by gfs_controld in gfs2-utils).
  7.  
  8. A list of GFS2 uevents
  9. -----------------------
  10.  
  11. 1. ADD
  12.  
  13. The ADD event occurs at mount time. It will always be the first
  14. uevent generated by the newly created filesystem. If the mount
  15. is successful, an ONLINE uevent will follow.  If it is not successful
  16. then a REMOVE uevent will follow.
  17.  
  18. The ADD uevent has two environment variables: SPECTATOR=[0|1]
  19. and RDONLY=[0|1] that specify the spectator status (a read-only mount
  20. with no journal assigned), and read-only (with journal assigned) status
  21. of the filesystem respectively.
  22.  
  23. 2. ONLINE
  24.  
  25. The ONLINE uevent is generated after a successful mount or remount. It
  26. has the same environment variables as the ADD uevent. The ONLINE
  27. uevent, along with the two environment variables for spectator and
  28. RDONLY are a relatively recent addition (2.6.32-rc+) and will not
  29. be generated by older kernels.
  30.  
  31. 3. CHANGE
  32.  
  33. The CHANGE uevent is used in two places. One is when reporting the
  34. successful mount of the filesystem by the first node (FIRSTMOUNT=Done).
  35. This is used as a signal by gfs_controld that it is then ok for other
  36. nodes in the cluster to mount the filesystem.
  37.  
  38. The other CHANGE uevent is used to inform of the completion
  39. of journal recovery for one of the filesystems journals. It has
  40. two environment variables, JID= which specifies the journal id which
  41. has just been recovered, and RECOVERY=[Done|Failed] to indicate the
  42. success (or otherwise) of the operation. These uevents are generated
  43. for every journal recovered, whether it is during the initial mount
  44. process or as the result of gfs_controld requesting a specific journal
  45. recovery via the /sys/fs/gfs2/<fsname>/lock_module/recovery file.
  46.  
  47. Because the CHANGE uevent was used (in early versions of gfs_controld)
  48. without checking the environment variables to discover the state, we
  49. cannot add any more functions to it without running the risk of
  50. someone using an older version of the user tools and breaking their
  51. cluster. For this reason the ONLINE uevent was used when adding a new
  52. uevent for a successful mount or remount.
  53.  
  54. 4. OFFLINE
  55.  
  56. The OFFLINE uevent is only generated due to filesystem errors and is used
  57. as part of the "withdraw" mechanism. Currently this doesn't give any
  58. information about what the error is, which is something that needs to
  59. be fixed.
  60.  
  61. 5. REMOVE
  62.  
  63. The REMOVE uevent is generated at the end of an unsuccessful mount
  64. or at the end of a umount of the filesystem. All REMOVE uevents will
  65. have been preceded by at least an ADD uevent for the same filesystem,
  66. and unlike the other uevents is generated automatically by the kernel's
  67. kobject subsystem.
  68.  
  69.  
  70. Information common to all GFS2 uevents (uevent environment variables)
  71. ----------------------------------------------------------------------
  72.  
  73. 1. LOCKTABLE=
  74.  
  75. The LOCKTABLE is a string, as supplied on the mount command
  76. line (locktable=) or via fstab. It is used as a filesystem label
  77. as well as providing the information for a lock_dlm mount to be
  78. able to join the cluster.
  79.  
  80. 2. LOCKPROTO=
  81.  
  82. The LOCKPROTO is a string, and its value depends on what is set
  83. on the mount command line, or via fstab. It will be either
  84. lock_nolock or lock_dlm. In the future other lock managers
  85. may be supported.
  86.  
  87. 3. JOURNALID=
  88.  
  89. If a journal is in use by the filesystem (journals are not
  90. assigned for spectator mounts) then this will give the
  91. numeric journal id in all GFS2 uevents.
  92.  
  93. 4. UUID=
  94.  
  95. With recent versions of gfs2-utils, mkfs.gfs2 writes a UUID
  96. into the filesystem superblock. If it exists, this will
  97. be included in every uevent relating to the filesystem.

Raw Paste


Login or Register to edit or fork this paste. It's free.