diff options
| author | Andreas Gruenbacher <agruenba@redhat.com> | 2023-01-24 14:14:42 +0100 |
|---|---|---|
| committer | Andreas Gruenbacher <agruenba@redhat.com> | 2023-01-31 22:40:18 +0100 |
| commit | 2d1439557ffeab3b9729f1c64fa86830070f9a04 (patch) | |
| tree | cc83d0fdc4d2c38db16147b2de5c77ad480d4c0e /fs/gfs2/super.c | |
| parent | 9ffa18884cceb2e5731e422140fad06292de0577 (diff) | |
| download | linux-2d1439557ffeab3b9729f1c64fa86830070f9a04.tar.gz linux-2d1439557ffeab3b9729f1c64fa86830070f9a04.tar.bz2 linux-2d1439557ffeab3b9729f1c64fa86830070f9a04.zip | |
gfs2: Improve gfs2_upgrade_iopen_glock comment
Improve the comment describing the inode and iopen glock interactions
and the glock poking related to inode evict.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Diffstat (limited to 'fs/gfs2/super.c')
| -rw-r--r-- | fs/gfs2/super.c | 24 |
1 files changed, 16 insertions, 8 deletions
diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c index de99505d49de..a857b99252ae 100644 --- a/fs/gfs2/super.c +++ b/fs/gfs2/super.c @@ -1175,15 +1175,23 @@ static bool gfs2_upgrade_iopen_glock(struct inode *inode) gfs2_glock_dq_wait(gh); /* - * If there are no other lock holders, we'll get the lock immediately. + * If there are no other lock holders, we will immediately get + * exclusive access to the iopen glock here. + * * Otherwise, the other nodes holding the lock will be notified about - * our locking request. If they don't have the inode open, they'll - * evict the cached inode and release the lock. Otherwise, if they - * poke the inode glock, we'll take this as an indication that they - * still need the iopen glock and that they'll take care of deleting - * the inode when they're done. As a last resort, if another node - * keeps holding the iopen glock without showing any activity on the - * inode glock, we'll eventually time out. + * our locking request. If they do not have the inode open, they are + * expected to evict the cached inode and release the lock, allowing us + * to proceed. + * + * Otherwise, if they cannot evict the inode, they are expected to poke + * the inode glock (note: not the iopen glock). We will notice that + * and stop waiting for the iopen glock immediately. The other node(s) + * are then expected to take care of deleting the inode when they no + * longer use it. + * + * As a last resort, if another node keeps holding the iopen glock + * without showing any activity on the inode glock, we will eventually + * time out and fail the iopen glock upgrade. * * Note that we're passing the LM_FLAG_TRY_1CB flag to the first * locking request as an optimization to notify lock holders as soon as |