|
| 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 preceeded by at least an ADD uevent for the same fileystem, |
| 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. |
| 98 | + |
| 99 | + |
| 100 | + |
0 commit comments