^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 1) .. SPDX-License-Identifier: GPL-2.0
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 2)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 3) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 4) Glock internal locking rules
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 5) ============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 6)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 7) This documents the basic principles of the glock state machine
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 8) internals. Each glock (struct gfs2_glock in fs/gfs2/incore.h)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 9) has two main (internal) locks:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 10)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 11) 1. A spinlock (gl_lockref.lock) which protects the internal state such
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 12) as gl_state, gl_target and the list of holders (gl_holders)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 13) 2. A non-blocking bit lock, GLF_LOCK, which is used to prevent other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 14) threads from making calls to the DLM, etc. at the same time. If a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 15) thread takes this lock, it must then call run_queue (usually via the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 16) workqueue) when it releases it in order to ensure any pending tasks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 17) are completed.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 18)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 19) The gl_holders list contains all the queued lock requests (not
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 20) just the holders) associated with the glock. If there are any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 21) held locks, then they will be contiguous entries at the head
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 22) of the list. Locks are granted in strictly the order that they
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 23) are queued, except for those marked LM_FLAG_PRIORITY which are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 24) used only during recovery, and even then only for journal locks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 25)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 26) There are three lock states that users of the glock layer can request,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 27) namely shared (SH), deferred (DF) and exclusive (EX). Those translate
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 28) to the following DLM lock modes:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 29)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 30) ========== ====== =====================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 31) Glock mode DLM lock mode
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 32) ========== ====== =====================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 33) UN IV/NL Unlocked (no DLM lock associated with glock) or NL
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 34) SH PR (Protected read)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 35) DF CW (Concurrent write)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 36) EX EX (Exclusive)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 37) ========== ====== =====================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 38)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 39) Thus DF is basically a shared mode which is incompatible with the "normal"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 40) shared lock mode, SH. In GFS2 the DF mode is used exclusively for direct I/O
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 41) operations. The glocks are basically a lock plus some routines which deal
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 42) with cache management. The following rules apply for the cache:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 43)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 44) ========== ========== ============== ========== ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 45) Glock mode Cache data Cache Metadata Dirty Data Dirty Metadata
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 46) ========== ========== ============== ========== ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 47) UN No No No No
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 48) SH Yes Yes No No
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 49) DF No Yes No No
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 50) EX Yes Yes Yes Yes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 51) ========== ========== ============== ========== ==============
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 52)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 53) These rules are implemented using the various glock operations which
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 54) are defined for each type of glock. Not all types of glocks use
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 55) all the modes. Only inode glocks use the DF mode for example.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 56)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 57) Table of glock operations and per type constants:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 58)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 59) ============= =============================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 60) Field Purpose
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 61) ============= =============================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 62) go_xmote_th Called before remote state change (e.g. to sync dirty data)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 63) go_xmote_bh Called after remote state change (e.g. to refill cache)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 64) go_inval Called if remote state change requires invalidating the cache
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 65) go_demote_ok Returns boolean value of whether its ok to demote a glock
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 66) (e.g. checks timeout, and that there is no cached data)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 67) go_lock Called for the first local holder of a lock
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 68) go_unlock Called on the final local unlock of a lock
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 69) go_dump Called to print content of object for debugfs file, or on
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 70) error to dump glock to the log.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 71) go_type The type of the glock, ``LM_TYPE_*``
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 72) go_callback Called if the DLM sends a callback to drop this lock
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 73) go_flags GLOF_ASPACE is set, if the glock has an address space
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 74) associated with it
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 75) ============= =============================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 76)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 77) The minimum hold time for each lock is the time after a remote lock
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 78) grant for which we ignore remote demote requests. This is in order to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 79) prevent a situation where locks are being bounced around the cluster
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 80) from node to node with none of the nodes making any progress. This
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 81) tends to show up most with shared mmaped files which are being written
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 82) to by multiple nodes. By delaying the demotion in response to a
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 83) remote callback, that gives the userspace program time to make
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 84) some progress before the pages are unmapped.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 85)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 86) There is a plan to try and remove the go_lock and go_unlock callbacks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 87) if possible, in order to try and speed up the fast path though the locking.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 88) Also, eventually we hope to make the glock "EX" mode locally shared
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 89) such that any local locking will be done with the i_mutex as required
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 90) rather than via the glock.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 91)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 92) Locking rules for glock operations:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 93)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 94) ============= ====================== =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 95) Operation GLF_LOCK bit lock held gl_lockref.lock spinlock held
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 96) ============= ====================== =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 97) go_xmote_th Yes No
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 98) go_xmote_bh Yes No
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 99) go_inval Yes No
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 100) go_demote_ok Sometimes Yes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 101) go_lock Yes No
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 102) go_unlock Yes No
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 103) go_dump Sometimes Yes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 104) go_callback Sometimes (N/A) Yes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 105) ============= ====================== =============================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 106)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 107) .. Note::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 108)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 109) Operations must not drop either the bit lock or the spinlock
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 110) if its held on entry. go_dump and do_demote_ok must never block.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 111) Note that go_dump will only be called if the glock's state
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 112) indicates that it is caching uptodate data.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 113)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 114) Glock locking order within GFS2:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 115)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 116) 1. i_rwsem (if required)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 117) 2. Rename glock (for rename only)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 118) 3. Inode glock(s)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 119) (Parents before children, inodes at "same level" with same parent in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 120) lock number order)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 121) 4. Rgrp glock(s) (for (de)allocation operations)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 122) 5. Transaction glock (via gfs2_trans_begin) for non-read operations
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 123) 6. i_rw_mutex (if required)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 124) 7. Page lock (always last, very important!)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 125)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 126) There are two glocks per inode. One deals with access to the inode
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 127) itself (locking order as above), and the other, known as the iopen
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 128) glock is used in conjunction with the i_nlink field in the inode to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 129) determine the lifetime of the inode in question. Locking of inodes
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 130) is on a per-inode basis. Locking of rgrps is on a per rgrp basis.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 131) In general we prefer to lock local locks prior to cluster locks.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 132)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 133) Glock Statistics
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 134) ----------------
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 135)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 136) The stats are divided into two sets: those relating to the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 137) super block and those relating to an individual glock. The
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 138) super block stats are done on a per cpu basis in order to
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 139) try and reduce the overhead of gathering them. They are also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 140) further divided by glock type. All timings are in nanoseconds.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 141)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 142) In the case of both the super block and glock statistics,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 143) the same information is gathered in each case. The super
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 144) block timing statistics are used to provide default values for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 145) the glock timing statistics, so that newly created glocks
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 146) should have, as far as possible, a sensible starting point.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 147) The per-glock counters are initialised to zero when the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 148) glock is created. The per-glock statistics are lost when
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 149) the glock is ejected from memory.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 150)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 151) The statistics are divided into three pairs of mean and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 152) variance, plus two counters. The mean/variance pairs are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 153) smoothed exponential estimates and the algorithm used is
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 154) one which will be very familiar to those used to calculation
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 155) of round trip times in network code. See "TCP/IP Illustrated,
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 156) Volume 1", W. Richard Stevens, sect 21.3, "Round-Trip Time Measurement",
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 157) p. 299 and onwards. Also, Volume 2, Sect. 25.10, p. 838 and onwards.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 158) Unlike the TCP/IP Illustrated case, the mean and variance are
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 159) not scaled, but are in units of integer nanoseconds.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 160)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 161) The three pairs of mean/variance measure the following
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 162) things:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 163)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 164) 1. DLM lock time (non-blocking requests)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 165) 2. DLM lock time (blocking requests)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 166) 3. Inter-request time (again to the DLM)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 167)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 168) A non-blocking request is one which will complete right
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 169) away, whatever the state of the DLM lock in question. That
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 170) currently means any requests when (a) the current state of
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 171) the lock is exclusive, i.e. a lock demotion (b) the requested
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 172) state is either null or unlocked (again, a demotion) or (c) the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 173) "try lock" flag is set. A blocking request covers all the other
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 174) lock requests.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 175)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 176) There are two counters. The first is there primarily to show
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 177) how many lock requests have been made, and thus how much data
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 178) has gone into the mean/variance calculations. The other counter
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 179) is counting queuing of holders at the top layer of the glock
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 180) code. Hopefully that number will be a lot larger than the number
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 181) of dlm lock requests issued.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 182)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 183) So why gather these statistics? There are several reasons
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 184) we'd like to get a better idea of these timings:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 185)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 186) 1. To be able to better set the glock "min hold time"
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 187) 2. To spot performance issues more easily
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 188) 3. To improve the algorithm for selecting resource groups for
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 189) allocation (to base it on lock wait time, rather than blindly
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 190) using a "try lock")
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 191)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 192) Due to the smoothing action of the updates, a step change in
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 193) some input quantity being sampled will only fully be taken
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 194) into account after 8 samples (or 4 for the variance) and this
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 195) needs to be carefully considered when interpreting the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 196) results.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 197)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 198) Knowing both the time it takes a lock request to complete and
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 199) the average time between lock requests for a glock means we
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 200) can compute the total percentage of the time for which the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 201) node is able to use a glock vs. time that the rest of the
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 202) cluster has its share. That will be very useful when setting
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 203) the lock min hold time.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 204)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 205) Great care has been taken to ensure that we
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 206) measure exactly the quantities that we want, as accurately
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 207) as possible. There are always inaccuracies in any
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 208) measuring system, but I hope this is as accurate as we
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 209) can reasonably make it.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 210)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 211) Per sb stats can be found here::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 212)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 213) /sys/kernel/debug/gfs2/<fsname>/sbstats
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 214)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 215) Per glock stats can be found here::
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 216)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 217) /sys/kernel/debug/gfs2/<fsname>/glstats
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 218)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 219) Assuming that debugfs is mounted on /sys/kernel/debug and also
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 220) that <fsname> is replaced with the name of the gfs2 filesystem
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 221) in question.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 222)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 223) The abbreviations used in the output as are follows:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 224)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 225) ========= ================================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 226) srtt Smoothed round trip time for non blocking dlm requests
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 227) srttvar Variance estimate for srtt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 228) srttb Smoothed round trip time for (potentially) blocking dlm requests
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 229) srttvarb Variance estimate for srttb
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 230) sirt Smoothed inter request time (for dlm requests)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 231) sirtvar Variance estimate for sirt
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 232) dlm Number of dlm requests made (dcnt in glstats file)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 233) queue Number of glock requests queued (qcnt in glstats file)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 234) ========= ================================================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 235)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 236) The sbstats file contains a set of these stats for each glock type (so 8 lines
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 237) for each type) and for each cpu (one column per cpu). The glstats file contains
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 238) a set of these stats for each glock in a similar format to the glocks file, but
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 239) using the format mean/variance for each of the timing stats.
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 240)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 241) The gfs2_glock_lock_time tracepoint prints out the current values of the stats
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 242) for the glock in question, along with some addition information on each dlm
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 243) reply that is received:
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 244)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 245) ====== =======================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 246) status The status of the dlm request
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 247) flags The dlm request flags
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 248) tdiff The time taken by this specific request
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 249) ====== =======================================
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 250)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 251) (remaining fields as per above list)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 252)
^8f3ce5b39 (kx 2023-10-28 12:00:06 +0300 253)
Orange Pi5 kernel
Deprecated Linux kernel 5.10.110 for OrangePi 5/5B/5+ boards
3 Commits
0 Branches
0 Tags