gfs2: Introduce concept of a pending withdraw
authorBob Peterson <rpeterso@redhat.com>
Tue, 12 Feb 2019 20:43:55 +0000 (13:43 -0700)
committerBob Peterson <rpeterso@redhat.com>
Mon, 10 Feb 2020 13:39:47 +0000 (07:39 -0600)
commit69511080bd6efd34f4e020fcde6cf73bb4a61af6
tree28db914524c033ac6ac0366cdb571f5765ab4c0a
parent8e28ef1f2fa176854f96fb0416f2aaf5516793d0
gfs2: Introduce concept of a pending withdraw

File system withdraws can be delayed when inconsistencies are
discovered when we cannot withdraw immediately, for example, when
critical spin_locks are held. But delaying the withdraw can cause
gfs2 to ignore the error and keep running for a short period of time.
For example, an rgrp glock may be dequeued and demoted while there
are still buffers that haven't been properly revoked, due to io
errors writing to the journal.

This patch introduces a new concept of a pending withdraw, which
means an inconsistency has been discovered and we need to withdraw
at the earliest possible opportunity. In these cases, we aren't
quite withdrawn yet, but we still need to not dequeue glocks and
other critical things. If we dequeue the glocks and the withdraw
results in our journal being replayed, the replay could overwrite
data that's been modified by a different node that acquired the
glock in the meantime.

Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
fs/gfs2/incore.h
fs/gfs2/log.c
fs/gfs2/util.c
fs/gfs2/util.h