2019-05-31 16:09:56 +08:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2009-01-12 18:43:39 +08:00
|
|
|
/*
|
|
|
|
|
* Copyright (C) Sistina Software, Inc. 1997-2003 All rights reserved.
|
2012-01-10 06:18:05 +08:00
|
|
|
* Copyright 2004-2011 Red Hat, Inc.
|
2009-01-12 18:43:39 +08:00
|
|
|
*/
|
|
|
|
|
|
2014-03-07 04:10:45 +08:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
|
2009-01-12 18:43:39 +08:00
|
|
|
#include <linux/fs.h>
|
|
|
|
|
#include <linux/dlm.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 16:04:11 +08:00
|
|
|
#include <linux/slab.h>
|
2009-01-12 18:43:39 +08:00
|
|
|
#include <linux/types.h>
|
2012-01-10 06:18:05 +08:00
|
|
|
#include <linux/delay.h>
|
2009-01-12 18:43:39 +08:00
|
|
|
#include <linux/gfs2_ondisk.h>
|
2017-02-03 02:15:33 +08:00
|
|
|
#include <linux/sched/signal.h>
|
2009-01-12 18:43:39 +08:00
|
|
|
|
|
|
|
|
#include "incore.h"
|
|
|
|
|
#include "glock.h"
|
gfs2: Force withdraw to replay journals and wait for it to finish
When a node withdraws from a file system, it often leaves its journal
in an incomplete state. This is especially true when the withdraw is
caused by io errors writing to the journal. Before this patch, a
withdraw would try to write a "shutdown" record to the journal, tell
dlm it's done with the file system, and none of the other nodes
know about the problem. Later, when the problem is fixed and the
withdrawn node is rebooted, it would then discover that its own
journal was incomplete, and replay it. However, replaying it at this
point is almost guaranteed to introduce corruption because the other
nodes are likely to have used affected resource groups that appeared
in the journal since the time of the withdraw. Replaying the journal
later will overwrite any changes made, and not through any fault of
dlm, which was instructed during the withdraw to release those
resources.
This patch makes file system withdraws seen by the entire cluster.
Withdrawing nodes dequeue their journal glock to allow recovery.
The remaining nodes check all the journals to see if they are
clean or in need of replay. They try to replay dirty journals, but
only the journals of withdrawn nodes will be "not busy" and
therefore available for replay.
Until the journal replay is complete, no i/o related glocks may be
given out, to ensure that the replay does not cause the
aforementioned corruption: We cannot allow any journal replay to
overwrite blocks associated with a glock once it is held.
The "live" glock which is now used to signal when a withdraw
occurs. When a withdraw occurs, the node signals its withdraw by
dequeueing the "live" glock and trying to enqueue it in EX mode,
thus forcing the other nodes to all see a demote request, by way
of a "1CB" (one callback) try lock. The "live" glock is not
granted in EX; the callback is only just used to indicate a
withdraw has occurred.
Note that all nodes in the cluster must wait for the recovering
node to finish replaying the withdrawing node's journal before
continuing. To this end, it checks that the journals are clean
multiple times in a retry loop.
Also note that the withdraw function may be called from a wide
variety of situations, and therefore, we need to take extra
precautions to make sure pointers are valid before using them in
many circumstances.
We also need to take care when glocks decide to withdraw, since
the withdraw code now uses glocks.
Also, before this patch, if a process encountered an error and
decided to withdraw, if another process was already withdrawing,
the second withdraw would be silently ignored, which set it free
to unlock its glocks. That's correct behavior if the original
withdrawer encounters further errors down the road. But if
secondary waiters don't wait for the journal replay, unlocking
glocks will allow other nodes to use them, despite the fact that
the journal containing those blocks is being replayed. The
replay needs to finish before our glocks are released to other
nodes. IOW, secondary withdraws need to wait for the first
withdraw to finish.
For example, if an rgrp glock is unlocked by a process that didn't
wait for the first withdraw, a journal replay could introduce file
system corruption by replaying a rgrp block that has already been
granted to a different cluster node.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2020-01-29 03:23:45 +08:00
|
|
|
#include "glops.h"
|
|
|
|
|
#include "recovery.h"
|
2009-01-12 18:43:39 +08:00
|
|
|
#include "util.h"
|
2012-01-10 06:18:05 +08:00
|
|
|
#include "sys.h"
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
#include "trace_gfs2.h"
|
2009-01-12 18:43:39 +08:00
|
|
|
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
/**
|
|
|
|
|
* gfs2_update_stats - Update time based stats
|
2021-03-31 00:44:29 +08:00
|
|
|
* @s: The stats to update (local or global)
|
|
|
|
|
* @index: The index inside @s
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
* @sample: New data to include
|
|
|
|
|
*/
|
|
|
|
|
static inline void gfs2_update_stats(struct gfs2_lkstats *s, unsigned index,
|
|
|
|
|
s64 sample)
|
|
|
|
|
{
|
2021-03-31 00:44:29 +08:00
|
|
|
/*
|
|
|
|
|
* @delta is the difference between the current rtt sample and the
|
|
|
|
|
* running average srtt. We add 1/8 of that to the srtt in order to
|
|
|
|
|
* update the current srtt estimate. The variance estimate is a bit
|
|
|
|
|
* more complicated. We subtract the current variance estimate from
|
|
|
|
|
* the abs value of the @delta and add 1/4 of that to the running
|
|
|
|
|
* total. That's equivalent to 3/4 of the current variance
|
|
|
|
|
* estimate plus 1/4 of the abs of @delta.
|
|
|
|
|
*
|
|
|
|
|
* Note that the index points at the array entry containing the
|
|
|
|
|
* smoothed mean value, and the variance is always in the following
|
|
|
|
|
* entry
|
|
|
|
|
*
|
|
|
|
|
* Reference: TCP/IP Illustrated, vol 2, p. 831,832
|
|
|
|
|
* All times are in units of integer nanoseconds. Unlike the TCP/IP
|
|
|
|
|
* case, they are not scaled fixed point.
|
|
|
|
|
*/
|
|
|
|
|
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
s64 delta = sample - s->stats[index];
|
|
|
|
|
s->stats[index] += (delta >> 3);
|
|
|
|
|
index++;
|
2019-05-18 02:18:43 +08:00
|
|
|
s->stats[index] += (s64)(abs(delta) - s->stats[index]) >> 2;
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* gfs2_update_reply_times - Update locking statistics
|
|
|
|
|
* @gl: The glock to update
|
|
|
|
|
*
|
|
|
|
|
* This assumes that gl->gl_dstamp has been set earlier.
|
|
|
|
|
*
|
|
|
|
|
* The rtt (lock round trip time) is an estimate of the time
|
|
|
|
|
* taken to perform a dlm lock request. We update it on each
|
|
|
|
|
* reply from the dlm.
|
|
|
|
|
*
|
|
|
|
|
* The blocking flag is set on the glock for all dlm requests
|
|
|
|
|
* which may potentially block due to lock requests from other nodes.
|
|
|
|
|
* DLM requests where the current lock state is exclusive, the
|
|
|
|
|
* requested state is null (or unlocked) or where the TRY or
|
|
|
|
|
* TRY_1CB flags are set are classified as non-blocking. All
|
|
|
|
|
* other DLM requests are counted as (potentially) blocking.
|
|
|
|
|
*/
|
|
|
|
|
static inline void gfs2_update_reply_times(struct gfs2_glock *gl)
|
|
|
|
|
{
|
|
|
|
|
struct gfs2_pcpu_lkstats *lks;
|
|
|
|
|
const unsigned gltype = gl->gl_name.ln_type;
|
|
|
|
|
unsigned index = test_bit(GLF_BLOCKING, &gl->gl_flags) ?
|
|
|
|
|
GFS2_LKS_SRTTB : GFS2_LKS_SRTT;
|
|
|
|
|
s64 rtt;
|
|
|
|
|
|
|
|
|
|
preempt_disable();
|
|
|
|
|
rtt = ktime_to_ns(ktime_sub(ktime_get_real(), gl->gl_dstamp));
|
2015-03-17 00:52:05 +08:00
|
|
|
lks = this_cpu_ptr(gl->gl_name.ln_sbd->sd_lkstats);
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
gfs2_update_stats(&gl->gl_stats, index, rtt); /* Local */
|
|
|
|
|
gfs2_update_stats(&lks->lkstats[gltype], index, rtt); /* Global */
|
|
|
|
|
preempt_enable();
|
|
|
|
|
|
|
|
|
|
trace_gfs2_glock_lock_time(gl, rtt);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* gfs2_update_request_times - Update locking statistics
|
|
|
|
|
* @gl: The glock to update
|
|
|
|
|
*
|
|
|
|
|
* The irt (lock inter-request times) measures the average time
|
|
|
|
|
* between requests to the dlm. It is updated immediately before
|
|
|
|
|
* each dlm call.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
static inline void gfs2_update_request_times(struct gfs2_glock *gl)
|
|
|
|
|
{
|
|
|
|
|
struct gfs2_pcpu_lkstats *lks;
|
|
|
|
|
const unsigned gltype = gl->gl_name.ln_type;
|
|
|
|
|
ktime_t dstamp;
|
|
|
|
|
s64 irt;
|
|
|
|
|
|
|
|
|
|
preempt_disable();
|
|
|
|
|
dstamp = gl->gl_dstamp;
|
|
|
|
|
gl->gl_dstamp = ktime_get_real();
|
|
|
|
|
irt = ktime_to_ns(ktime_sub(gl->gl_dstamp, dstamp));
|
2015-03-17 00:52:05 +08:00
|
|
|
lks = this_cpu_ptr(gl->gl_name.ln_sbd->sd_lkstats);
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
gfs2_update_stats(&gl->gl_stats, GFS2_LKS_SIRT, irt); /* Local */
|
|
|
|
|
gfs2_update_stats(&lks->lkstats[gltype], GFS2_LKS_SIRT, irt); /* Global */
|
|
|
|
|
preempt_enable();
|
|
|
|
|
}
|
|
|
|
|
|
2009-01-12 18:43:39 +08:00
|
|
|
static void gdlm_ast(void *arg)
|
|
|
|
|
{
|
|
|
|
|
struct gfs2_glock *gl = arg;
|
|
|
|
|
unsigned ret = gl->gl_state;
|
|
|
|
|
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
gfs2_update_reply_times(gl);
|
2009-01-12 18:43:39 +08:00
|
|
|
BUG_ON(gl->gl_lksb.sb_flags & DLM_SBF_DEMOTED);
|
|
|
|
|
|
2012-11-15 02:47:37 +08:00
|
|
|
if ((gl->gl_lksb.sb_flags & DLM_SBF_VALNOTVALID) && gl->gl_lksb.sb_lvbptr)
|
|
|
|
|
memset(gl->gl_lksb.sb_lvbptr, 0, GDLM_LVB_SIZE);
|
2009-01-12 18:43:39 +08:00
|
|
|
|
|
|
|
|
switch (gl->gl_lksb.sb_status) {
|
|
|
|
|
case -DLM_EUNLOCK: /* Unlocked, so glock can be freed */
|
gfs2: Force withdraw to replay journals and wait for it to finish
When a node withdraws from a file system, it often leaves its journal
in an incomplete state. This is especially true when the withdraw is
caused by io errors writing to the journal. Before this patch, a
withdraw would try to write a "shutdown" record to the journal, tell
dlm it's done with the file system, and none of the other nodes
know about the problem. Later, when the problem is fixed and the
withdrawn node is rebooted, it would then discover that its own
journal was incomplete, and replay it. However, replaying it at this
point is almost guaranteed to introduce corruption because the other
nodes are likely to have used affected resource groups that appeared
in the journal since the time of the withdraw. Replaying the journal
later will overwrite any changes made, and not through any fault of
dlm, which was instructed during the withdraw to release those
resources.
This patch makes file system withdraws seen by the entire cluster.
Withdrawing nodes dequeue their journal glock to allow recovery.
The remaining nodes check all the journals to see if they are
clean or in need of replay. They try to replay dirty journals, but
only the journals of withdrawn nodes will be "not busy" and
therefore available for replay.
Until the journal replay is complete, no i/o related glocks may be
given out, to ensure that the replay does not cause the
aforementioned corruption: We cannot allow any journal replay to
overwrite blocks associated with a glock once it is held.
The "live" glock which is now used to signal when a withdraw
occurs. When a withdraw occurs, the node signals its withdraw by
dequeueing the "live" glock and trying to enqueue it in EX mode,
thus forcing the other nodes to all see a demote request, by way
of a "1CB" (one callback) try lock. The "live" glock is not
granted in EX; the callback is only just used to indicate a
withdraw has occurred.
Note that all nodes in the cluster must wait for the recovering
node to finish replaying the withdrawing node's journal before
continuing. To this end, it checks that the journals are clean
multiple times in a retry loop.
Also note that the withdraw function may be called from a wide
variety of situations, and therefore, we need to take extra
precautions to make sure pointers are valid before using them in
many circumstances.
We also need to take care when glocks decide to withdraw, since
the withdraw code now uses glocks.
Also, before this patch, if a process encountered an error and
decided to withdraw, if another process was already withdrawing,
the second withdraw would be silently ignored, which set it free
to unlock its glocks. That's correct behavior if the original
withdrawer encounters further errors down the road. But if
secondary waiters don't wait for the journal replay, unlocking
glocks will allow other nodes to use them, despite the fact that
the journal containing those blocks is being replayed. The
replay needs to finish before our glocks are released to other
nodes. IOW, secondary withdraws need to wait for the first
withdraw to finish.
For example, if an rgrp glock is unlocked by a process that didn't
wait for the first withdraw, a journal replay could introduce file
system corruption by replaying a rgrp block that has already been
granted to a different cluster node.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2020-01-29 03:23:45 +08:00
|
|
|
if (gl->gl_ops->go_free)
|
|
|
|
|
gl->gl_ops->go_free(gl);
|
2011-03-09 18:58:04 +08:00
|
|
|
gfs2_glock_free(gl);
|
2009-01-12 18:43:39 +08:00
|
|
|
return;
|
|
|
|
|
case -DLM_ECANCEL: /* Cancel while getting lock */
|
|
|
|
|
ret |= LM_OUT_CANCELED;
|
|
|
|
|
goto out;
|
|
|
|
|
case -EAGAIN: /* Try lock fails */
|
2010-09-08 17:09:25 +08:00
|
|
|
case -EDEADLK: /* Deadlock detected */
|
2009-01-12 18:43:39 +08:00
|
|
|
goto out;
|
2010-09-08 17:09:25 +08:00
|
|
|
case -ETIMEDOUT: /* Canceled due to timeout */
|
2009-01-12 18:43:39 +08:00
|
|
|
ret |= LM_OUT_ERROR;
|
|
|
|
|
goto out;
|
|
|
|
|
case 0: /* Success */
|
|
|
|
|
break;
|
|
|
|
|
default: /* Something unexpected */
|
|
|
|
|
BUG();
|
|
|
|
|
}
|
|
|
|
|
|
GFS2: Fix locking bug in failed shared to exclusive conversion
After calling out to the dlm, GFS2 sets the new state of a glock to
gl_target in gdlm_ast(). However, gl_target is not always the lock
state that was requested. If a conversion from shared to exclusive
fails, finish_xmote() will call do_xmote() with LM_ST_UNLOCKED, instead
of gl->gl_target, so that it can reacquire the lock in exlusive the next
time around. In this case, setting the lock to gl_target in gdlm_ast()
will make GFS2 think that it has the glock in exclusive mode, when
really, it doesn't have the glock locked at all. This patch adds a new
field to the gfs2_glock structure, gl_req, to track the mode that was
requested.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2009-03-07 00:03:20 +08:00
|
|
|
ret = gl->gl_req;
|
2009-01-12 18:43:39 +08:00
|
|
|
if (gl->gl_lksb.sb_flags & DLM_SBF_ALTMODE) {
|
GFS2: Fix locking bug in failed shared to exclusive conversion
After calling out to the dlm, GFS2 sets the new state of a glock to
gl_target in gdlm_ast(). However, gl_target is not always the lock
state that was requested. If a conversion from shared to exclusive
fails, finish_xmote() will call do_xmote() with LM_ST_UNLOCKED, instead
of gl->gl_target, so that it can reacquire the lock in exlusive the next
time around. In this case, setting the lock to gl_target in gdlm_ast()
will make GFS2 think that it has the glock in exclusive mode, when
really, it doesn't have the glock locked at all. This patch adds a new
field to the gfs2_glock structure, gl_req, to track the mode that was
requested.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2009-03-07 00:03:20 +08:00
|
|
|
if (gl->gl_req == LM_ST_SHARED)
|
2009-01-12 18:43:39 +08:00
|
|
|
ret = LM_ST_DEFERRED;
|
GFS2: Fix locking bug in failed shared to exclusive conversion
After calling out to the dlm, GFS2 sets the new state of a glock to
gl_target in gdlm_ast(). However, gl_target is not always the lock
state that was requested. If a conversion from shared to exclusive
fails, finish_xmote() will call do_xmote() with LM_ST_UNLOCKED, instead
of gl->gl_target, so that it can reacquire the lock in exlusive the next
time around. In this case, setting the lock to gl_target in gdlm_ast()
will make GFS2 think that it has the glock in exclusive mode, when
really, it doesn't have the glock locked at all. This patch adds a new
field to the gfs2_glock structure, gl_req, to track the mode that was
requested.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2009-03-07 00:03:20 +08:00
|
|
|
else if (gl->gl_req == LM_ST_DEFERRED)
|
2009-01-12 18:43:39 +08:00
|
|
|
ret = LM_ST_SHARED;
|
|
|
|
|
else
|
|
|
|
|
BUG();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
set_bit(GLF_INITIAL, &gl->gl_flags);
|
|
|
|
|
gfs2_glock_complete(gl, ret);
|
|
|
|
|
return;
|
|
|
|
|
out:
|
|
|
|
|
if (!test_bit(GLF_INITIAL, &gl->gl_flags))
|
|
|
|
|
gl->gl_lksb.sb_lkid = 0;
|
|
|
|
|
gfs2_glock_complete(gl, ret);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void gdlm_bast(void *arg, int mode)
|
|
|
|
|
{
|
|
|
|
|
struct gfs2_glock *gl = arg;
|
|
|
|
|
|
|
|
|
|
switch (mode) {
|
|
|
|
|
case DLM_LOCK_EX:
|
|
|
|
|
gfs2_glock_cb(gl, LM_ST_UNLOCKED);
|
|
|
|
|
break;
|
|
|
|
|
case DLM_LOCK_CW:
|
|
|
|
|
gfs2_glock_cb(gl, LM_ST_DEFERRED);
|
|
|
|
|
break;
|
|
|
|
|
case DLM_LOCK_PR:
|
|
|
|
|
gfs2_glock_cb(gl, LM_ST_SHARED);
|
|
|
|
|
break;
|
|
|
|
|
default:
|
2018-10-03 21:47:36 +08:00
|
|
|
fs_err(gl->gl_name.ln_sbd, "unknown bast mode %d\n", mode);
|
2009-01-12 18:43:39 +08:00
|
|
|
BUG();
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* convert gfs lock-state to dlm lock-mode */
|
|
|
|
|
|
2018-10-03 21:47:36 +08:00
|
|
|
static int make_mode(struct gfs2_sbd *sdp, const unsigned int lmstate)
|
2009-01-12 18:43:39 +08:00
|
|
|
{
|
|
|
|
|
switch (lmstate) {
|
|
|
|
|
case LM_ST_UNLOCKED:
|
|
|
|
|
return DLM_LOCK_NL;
|
|
|
|
|
case LM_ST_EXCLUSIVE:
|
|
|
|
|
return DLM_LOCK_EX;
|
|
|
|
|
case LM_ST_DEFERRED:
|
|
|
|
|
return DLM_LOCK_CW;
|
|
|
|
|
case LM_ST_SHARED:
|
|
|
|
|
return DLM_LOCK_PR;
|
|
|
|
|
}
|
2018-10-03 21:47:36 +08:00
|
|
|
fs_err(sdp, "unknown LM state %d\n", lmstate);
|
2009-01-12 18:43:39 +08:00
|
|
|
BUG();
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
GFS2: Instruct DLM to avoid queue convert slowdown
This patch instructs DLM to prevent an "in place" conversion, where the
lock just stays on the granted queue, and instead forces the conversion to
the back of the convert queue. This is done on upward conversions only.
This is useful in cases where, for example, a lock is frequently needed in
PR on one node, but another node needs it temporarily in EX to update it.
This may happen, for example, when the rindex is being updated by gfs2_grow.
The gfs2_grow needs to have the lock in EX, but the other nodes need to
re-read it to retrieve the updates. The glock is already granted in PR on
the non-growing nodes, so this prevents them from continually re-granting
the lock in PR, and forces the EX from gfs2_grow to go through.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-04-11 02:45:24 +08:00
|
|
|
static u32 make_flags(struct gfs2_glock *gl, const unsigned int gfs_flags,
|
2009-01-12 18:43:39 +08:00
|
|
|
const int req)
|
|
|
|
|
{
|
2012-11-15 02:46:53 +08:00
|
|
|
u32 lkf = 0;
|
|
|
|
|
|
2012-11-15 02:47:37 +08:00
|
|
|
if (gl->gl_lksb.sb_lvbptr)
|
2012-11-15 02:46:53 +08:00
|
|
|
lkf |= DLM_LKF_VALBLK;
|
2009-01-12 18:43:39 +08:00
|
|
|
|
|
|
|
|
if (gfs_flags & LM_FLAG_TRY)
|
|
|
|
|
lkf |= DLM_LKF_NOQUEUE;
|
|
|
|
|
|
|
|
|
|
if (gfs_flags & LM_FLAG_TRY_1CB) {
|
|
|
|
|
lkf |= DLM_LKF_NOQUEUE;
|
|
|
|
|
lkf |= DLM_LKF_NOQUEUEBAST;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (gfs_flags & LM_FLAG_PRIORITY) {
|
|
|
|
|
lkf |= DLM_LKF_NOORDER;
|
|
|
|
|
lkf |= DLM_LKF_HEADQUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (gfs_flags & LM_FLAG_ANY) {
|
|
|
|
|
if (req == DLM_LOCK_PR)
|
|
|
|
|
lkf |= DLM_LKF_ALTCW;
|
|
|
|
|
else if (req == DLM_LOCK_CW)
|
|
|
|
|
lkf |= DLM_LKF_ALTPR;
|
|
|
|
|
else
|
|
|
|
|
BUG();
|
|
|
|
|
}
|
|
|
|
|
|
2012-11-15 02:46:53 +08:00
|
|
|
if (gl->gl_lksb.sb_lkid != 0) {
|
2009-01-12 18:43:39 +08:00
|
|
|
lkf |= DLM_LKF_CONVERT;
|
GFS2: Instruct DLM to avoid queue convert slowdown
This patch instructs DLM to prevent an "in place" conversion, where the
lock just stays on the granted queue, and instead forces the conversion to
the back of the convert queue. This is done on upward conversions only.
This is useful in cases where, for example, a lock is frequently needed in
PR on one node, but another node needs it temporarily in EX to update it.
This may happen, for example, when the rindex is being updated by gfs2_grow.
The gfs2_grow needs to have the lock in EX, but the other nodes need to
re-read it to retrieve the updates. The glock is already granted in PR on
the non-growing nodes, so this prevents them from continually re-granting
the lock in PR, and forces the EX from gfs2_grow to go through.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-04-11 02:45:24 +08:00
|
|
|
if (test_bit(GLF_BLOCKING, &gl->gl_flags))
|
|
|
|
|
lkf |= DLM_LKF_QUECVT;
|
|
|
|
|
}
|
2009-01-12 18:43:39 +08:00
|
|
|
|
|
|
|
|
return lkf;
|
|
|
|
|
}
|
|
|
|
|
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
static void gfs2_reverse_hex(char *c, u64 value)
|
|
|
|
|
{
|
2012-12-12 06:01:24 +08:00
|
|
|
*c = '0';
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
while (value) {
|
|
|
|
|
*c-- = hex_asc[value & 0x0f];
|
|
|
|
|
value >>= 4;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2010-11-29 20:50:38 +08:00
|
|
|
static int gdlm_lock(struct gfs2_glock *gl, unsigned int req_state,
|
|
|
|
|
unsigned int flags)
|
2009-01-12 18:43:39 +08:00
|
|
|
{
|
2015-03-17 00:52:05 +08:00
|
|
|
struct lm_lockstruct *ls = &gl->gl_name.ln_sbd->sd_lockstruct;
|
2009-01-12 18:43:39 +08:00
|
|
|
int req;
|
|
|
|
|
u32 lkf;
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
char strname[GDLM_STRNAME_BYTES] = "";
|
gfs2: Expect -EBUSY after canceling dlm locking requests
Due to the asynchronous nature of the dlm api, when we request a pending
locking request to be canceled with dlm_unlock(DLM_LKF_CANCEL), the
locking request will either complete before it could be canceled, or the
cancellation will succeed. In either case, gdlm_ast will be called once
and the status will indicate the outcome of the locking request, with
-DLM_ECANCEL indicating a canceled request.
Inside dlm, when a locking request completes before its cancel request
could be processed, gdlm_ast will be called, but the lock will still be
considered busy until a DLM_MSG_CANCEL_REPLY message completes the
cancel request. During that time, successive dlm_lock() or dlm_unlock()
requests for that lock will return -EBUSY. In other words, waiting for
the gdlm_ast call before issuing the next locking request is not enough.
There is no way of waiting for a cancel request to actually complete,
either.
We rarely cancel locking requests, but when we do, we don't know when
the next locking request for that lock will occur. This means that any
dlm_lock() or dlm_unlock() call can potentially return -EBUSY. When
that happens, this patch simply repeats the request after a short pause.
This workaround could be improved upon by tracking for which dlm locks
cancel requests have been issued, but that isn't strictly necessary and
it would complicate the code. We haven't seen -EBUSY errors from dlm
without cancel requests.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2022-02-02 18:00:48 +08:00
|
|
|
int error;
|
2009-01-12 18:43:39 +08:00
|
|
|
|
2018-10-03 21:47:36 +08:00
|
|
|
req = make_mode(gl->gl_name.ln_sbd, req_state);
|
GFS2: Instruct DLM to avoid queue convert slowdown
This patch instructs DLM to prevent an "in place" conversion, where the
lock just stays on the granted queue, and instead forces the conversion to
the back of the convert queue. This is done on upward conversions only.
This is useful in cases where, for example, a lock is frequently needed in
PR on one node, but another node needs it temporarily in EX to update it.
This may happen, for example, when the rindex is being updated by gfs2_grow.
The gfs2_grow needs to have the lock in EX, but the other nodes need to
re-read it to retrieve the updates. The glock is already granted in PR on
the non-growing nodes, so this prevents them from continually re-granting
the lock in PR, and forces the EX from gfs2_grow to go through.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-04-11 02:45:24 +08:00
|
|
|
lkf = make_flags(gl, flags, req);
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
gfs2_glstats_inc(gl, GFS2_LKS_DCOUNT);
|
|
|
|
|
gfs2_sbstats_inc(gl, GFS2_LKS_DCOUNT);
|
|
|
|
|
if (gl->gl_lksb.sb_lkid) {
|
|
|
|
|
gfs2_update_request_times(gl);
|
|
|
|
|
} else {
|
|
|
|
|
memset(strname, ' ', GDLM_STRNAME_BYTES - 1);
|
|
|
|
|
strname[GDLM_STRNAME_BYTES - 1] = '\0';
|
|
|
|
|
gfs2_reverse_hex(strname + 7, gl->gl_name.ln_type);
|
|
|
|
|
gfs2_reverse_hex(strname + 23, gl->gl_name.ln_number);
|
|
|
|
|
gl->gl_dstamp = ktime_get_real();
|
|
|
|
|
}
|
2009-01-12 18:43:39 +08:00
|
|
|
/*
|
|
|
|
|
* Submit the actual lock request.
|
|
|
|
|
*/
|
|
|
|
|
|
gfs2: Expect -EBUSY after canceling dlm locking requests
Due to the asynchronous nature of the dlm api, when we request a pending
locking request to be canceled with dlm_unlock(DLM_LKF_CANCEL), the
locking request will either complete before it could be canceled, or the
cancellation will succeed. In either case, gdlm_ast will be called once
and the status will indicate the outcome of the locking request, with
-DLM_ECANCEL indicating a canceled request.
Inside dlm, when a locking request completes before its cancel request
could be processed, gdlm_ast will be called, but the lock will still be
considered busy until a DLM_MSG_CANCEL_REPLY message completes the
cancel request. During that time, successive dlm_lock() or dlm_unlock()
requests for that lock will return -EBUSY. In other words, waiting for
the gdlm_ast call before issuing the next locking request is not enough.
There is no way of waiting for a cancel request to actually complete,
either.
We rarely cancel locking requests, but when we do, we don't know when
the next locking request for that lock will occur. This means that any
dlm_lock() or dlm_unlock() call can potentially return -EBUSY. When
that happens, this patch simply repeats the request after a short pause.
This workaround could be improved upon by tracking for which dlm locks
cancel requests have been issued, but that isn't strictly necessary and
it would complicate the code. We haven't seen -EBUSY errors from dlm
without cancel requests.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2022-02-02 18:00:48 +08:00
|
|
|
again:
|
|
|
|
|
error = dlm_lock(ls->ls_dlm, req, &gl->gl_lksb, lkf, strname,
|
2010-11-29 20:50:38 +08:00
|
|
|
GDLM_STRNAME_BYTES - 1, 0, gdlm_ast, gl, gdlm_bast);
|
gfs2: Expect -EBUSY after canceling dlm locking requests
Due to the asynchronous nature of the dlm api, when we request a pending
locking request to be canceled with dlm_unlock(DLM_LKF_CANCEL), the
locking request will either complete before it could be canceled, or the
cancellation will succeed. In either case, gdlm_ast will be called once
and the status will indicate the outcome of the locking request, with
-DLM_ECANCEL indicating a canceled request.
Inside dlm, when a locking request completes before its cancel request
could be processed, gdlm_ast will be called, but the lock will still be
considered busy until a DLM_MSG_CANCEL_REPLY message completes the
cancel request. During that time, successive dlm_lock() or dlm_unlock()
requests for that lock will return -EBUSY. In other words, waiting for
the gdlm_ast call before issuing the next locking request is not enough.
There is no way of waiting for a cancel request to actually complete,
either.
We rarely cancel locking requests, but when we do, we don't know when
the next locking request for that lock will occur. This means that any
dlm_lock() or dlm_unlock() call can potentially return -EBUSY. When
that happens, this patch simply repeats the request after a short pause.
This workaround could be improved upon by tracking for which dlm locks
cancel requests have been issued, but that isn't strictly necessary and
it would complicate the code. We haven't seen -EBUSY errors from dlm
without cancel requests.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2022-02-02 18:00:48 +08:00
|
|
|
if (error == -EBUSY) {
|
|
|
|
|
msleep(20);
|
|
|
|
|
goto again;
|
|
|
|
|
}
|
|
|
|
|
return error;
|
2009-01-12 18:43:39 +08:00
|
|
|
}
|
|
|
|
|
|
2011-01-19 17:30:01 +08:00
|
|
|
static void gdlm_put_lock(struct gfs2_glock *gl)
|
2009-01-12 18:43:39 +08:00
|
|
|
{
|
2015-03-17 00:52:05 +08:00
|
|
|
struct gfs2_sbd *sdp = gl->gl_name.ln_sbd;
|
2010-01-25 19:20:19 +08:00
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
2009-01-12 18:43:39 +08:00
|
|
|
int error;
|
|
|
|
|
|
|
|
|
|
if (gl->gl_lksb.sb_lkid == 0) {
|
2011-03-09 18:58:04 +08:00
|
|
|
gfs2_glock_free(gl);
|
2009-01-12 18:43:39 +08:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
GFS2: glock statistics gathering
The stats are divided into two sets: those relating to the
super block and those relating to an individual glock. The
super block stats are done on a per cpu basis in order to
try and reduce the overhead of gathering them. They are also
further divided by glock type.
In the case of both the super block and glock statistics,
the same information is gathered in each case. The super
block statistics are used to provide default values for
most of the glock statistics, so that newly created glocks
should have, as far as possible, a sensible starting point.
The statistics are divided into three pairs of mean and
variance, plus two counters. The mean/variance pairs are
smoothed exponential estimates and the algorithm used is
one which will be very familiar to those used to calculation
of round trip times in network code.
The three pairs of mean/variance measure the following
things:
1. DLM lock time (non-blocking requests)
2. DLM lock time (blocking requests)
3. Inter-request time (again to the DLM)
A non-blocking request is one which will complete right
away, whatever the state of the DLM lock in question. That
currently means any requests when (a) the current state of
the lock is exclusive (b) the requested state is either null
or unlocked or (c) the "try lock" flag is set. A blocking
request covers all the other lock requests.
There are two counters. The first is there primarily to show
how many lock requests have been made, and thus how much data
has gone into the mean/variance calculations. The other counter
is counting queueing of holders at the top layer of the glock
code. Hopefully that number will be a lot larger than the number
of dlm lock requests issued.
So why gather these statistics? There are several reasons
we'd like to get a better idea of these timings:
1. To be able to better set the glock "min hold time"
2. To spot performance issues more easily
3. To improve the algorithm for selecting resource groups for
allocation (to base it on lock wait time, rather than blindly
using a "try lock")
Due to the smoothing action of the updates, a step change in
some input quantity being sampled will only fully be taken
into account after 8 samples (or 4 for the variance) and this
needs to be carefully considered when interpreting the
results.
Knowing both the time it takes a lock request to complete and
the average time between lock requests for a glock means we
can compute the total percentage of the time for which the
node is able to use a glock vs. time that the rest of the
cluster has its share. That will be very useful when setting
the lock min hold time.
The other point to remember is that all times are in
nanoseconds. Great care has been taken to ensure that we
measure exactly the quantities that we want, as accurately
as possible. There are always inaccuracies in any
measuring system, but I hope this is as accurate as we
can reasonably make it.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-01-20 18:38:36 +08:00
|
|
|
clear_bit(GLF_BLOCKING, &gl->gl_flags);
|
|
|
|
|
gfs2_glstats_inc(gl, GFS2_LKS_DCOUNT);
|
|
|
|
|
gfs2_sbstats_inc(gl, GFS2_LKS_DCOUNT);
|
|
|
|
|
gfs2_update_request_times(gl);
|
2012-11-13 23:58:56 +08:00
|
|
|
|
2021-07-31 01:41:49 +08:00
|
|
|
/* don't want to call dlm if we've unmounted the lock protocol */
|
|
|
|
|
if (test_bit(DFL_UNMOUNT, &ls->ls_recover_flags)) {
|
|
|
|
|
gfs2_glock_free(gl);
|
|
|
|
|
return;
|
|
|
|
|
}
|
gfs2: Don't skip dlm unlock if glock has an lvb
Patch fb6791d100d1 was designed to allow gfs2 to unmount quicker by
skipping the step where it tells dlm to unlock glocks in EX with lvbs.
This was done because when gfs2 unmounts a file system, it destroys the
dlm lockspace shortly after it destroys the glocks so it doesn't need to
unlock them all: the unlock is implied when the lockspace is destroyed
by dlm.
However, that patch introduced a use-after-free in dlm: as part of its
normal dlm_recoverd process, it can call ls_recovery to recover dead
locks. In so doing, it can call recover_rsbs which calls recover_lvb for
any mastered rsbs. Func recover_lvb runs through the list of lkbs queued
to the given rsb (if the glock is cached but unlocked, it will still be
queued to the lkb, but in NL--Unlocked--mode) and if it has an lvb,
copies it to the rsb, thus trying to preserve the lkb. However, when
gfs2 skips the dlm unlock step, it frees the glock and its lvb, which
means dlm's function recover_lvb references the now freed lvb pointer,
copying the freed lvb memory to the rsb.
This patch changes the check in gdlm_put_lock so that it calls
dlm_unlock for all glocks that contain an lvb pointer.
Fixes: fb6791d100d1 ("GFS2: skip dlm_unlock calls in unmount")
Cc: stable@vger.kernel.org # v3.8+
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2021-02-06 02:50:41 +08:00
|
|
|
/* don't want to skip dlm_unlock writing the lvb when lock has one */
|
2013-01-04 06:52:07 +08:00
|
|
|
|
2012-11-13 23:58:56 +08:00
|
|
|
if (test_bit(SDF_SKIP_DLM_UNLOCK, &sdp->sd_flags) &&
|
gfs2: Don't skip dlm unlock if glock has an lvb
Patch fb6791d100d1 was designed to allow gfs2 to unmount quicker by
skipping the step where it tells dlm to unlock glocks in EX with lvbs.
This was done because when gfs2 unmounts a file system, it destroys the
dlm lockspace shortly after it destroys the glocks so it doesn't need to
unlock them all: the unlock is implied when the lockspace is destroyed
by dlm.
However, that patch introduced a use-after-free in dlm: as part of its
normal dlm_recoverd process, it can call ls_recovery to recover dead
locks. In so doing, it can call recover_rsbs which calls recover_lvb for
any mastered rsbs. Func recover_lvb runs through the list of lkbs queued
to the given rsb (if the glock is cached but unlocked, it will still be
queued to the lkb, but in NL--Unlocked--mode) and if it has an lvb,
copies it to the rsb, thus trying to preserve the lkb. However, when
gfs2 skips the dlm unlock step, it frees the glock and its lvb, which
means dlm's function recover_lvb references the now freed lvb pointer,
copying the freed lvb memory to the rsb.
This patch changes the check in gdlm_put_lock so that it calls
dlm_unlock for all glocks that contain an lvb pointer.
Fixes: fb6791d100d1 ("GFS2: skip dlm_unlock calls in unmount")
Cc: stable@vger.kernel.org # v3.8+
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2021-02-06 02:50:41 +08:00
|
|
|
!gl->gl_lksb.sb_lvbptr) {
|
2012-11-13 23:58:56 +08:00
|
|
|
gfs2_glock_free(gl);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
gfs2: Expect -EBUSY after canceling dlm locking requests
Due to the asynchronous nature of the dlm api, when we request a pending
locking request to be canceled with dlm_unlock(DLM_LKF_CANCEL), the
locking request will either complete before it could be canceled, or the
cancellation will succeed. In either case, gdlm_ast will be called once
and the status will indicate the outcome of the locking request, with
-DLM_ECANCEL indicating a canceled request.
Inside dlm, when a locking request completes before its cancel request
could be processed, gdlm_ast will be called, but the lock will still be
considered busy until a DLM_MSG_CANCEL_REPLY message completes the
cancel request. During that time, successive dlm_lock() or dlm_unlock()
requests for that lock will return -EBUSY. In other words, waiting for
the gdlm_ast call before issuing the next locking request is not enough.
There is no way of waiting for a cancel request to actually complete,
either.
We rarely cancel locking requests, but when we do, we don't know when
the next locking request for that lock will occur. This means that any
dlm_lock() or dlm_unlock() call can potentially return -EBUSY. When
that happens, this patch simply repeats the request after a short pause.
This workaround could be improved upon by tracking for which dlm locks
cancel requests have been issued, but that isn't strictly necessary and
it would complicate the code. We haven't seen -EBUSY errors from dlm
without cancel requests.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2022-02-02 18:00:48 +08:00
|
|
|
again:
|
2009-01-12 18:43:39 +08:00
|
|
|
error = dlm_unlock(ls->ls_dlm, gl->gl_lksb.sb_lkid, DLM_LKF_VALBLK,
|
|
|
|
|
NULL, gl);
|
gfs2: Expect -EBUSY after canceling dlm locking requests
Due to the asynchronous nature of the dlm api, when we request a pending
locking request to be canceled with dlm_unlock(DLM_LKF_CANCEL), the
locking request will either complete before it could be canceled, or the
cancellation will succeed. In either case, gdlm_ast will be called once
and the status will indicate the outcome of the locking request, with
-DLM_ECANCEL indicating a canceled request.
Inside dlm, when a locking request completes before its cancel request
could be processed, gdlm_ast will be called, but the lock will still be
considered busy until a DLM_MSG_CANCEL_REPLY message completes the
cancel request. During that time, successive dlm_lock() or dlm_unlock()
requests for that lock will return -EBUSY. In other words, waiting for
the gdlm_ast call before issuing the next locking request is not enough.
There is no way of waiting for a cancel request to actually complete,
either.
We rarely cancel locking requests, but when we do, we don't know when
the next locking request for that lock will occur. This means that any
dlm_lock() or dlm_unlock() call can potentially return -EBUSY. When
that happens, this patch simply repeats the request after a short pause.
This workaround could be improved upon by tracking for which dlm locks
cancel requests have been issued, but that isn't strictly necessary and
it would complicate the code. We haven't seen -EBUSY errors from dlm
without cancel requests.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2022-02-02 18:00:48 +08:00
|
|
|
if (error == -EBUSY) {
|
|
|
|
|
msleep(20);
|
|
|
|
|
goto again;
|
|
|
|
|
}
|
|
|
|
|
|
2009-01-12 18:43:39 +08:00
|
|
|
if (error) {
|
2018-10-03 21:47:36 +08:00
|
|
|
fs_err(sdp, "gdlm_unlock %x,%llx err=%d\n",
|
2014-03-07 04:10:45 +08:00
|
|
|
gl->gl_name.ln_type,
|
2009-01-12 18:43:39 +08:00
|
|
|
(unsigned long long)gl->gl_name.ln_number, error);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void gdlm_cancel(struct gfs2_glock *gl)
|
|
|
|
|
{
|
2015-03-17 00:52:05 +08:00
|
|
|
struct lm_lockstruct *ls = &gl->gl_name.ln_sbd->sd_lockstruct;
|
2009-01-12 18:43:39 +08:00
|
|
|
dlm_unlock(ls->ls_dlm, gl->gl_lksb.sb_lkid, DLM_LKF_CANCEL, NULL, gl);
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-10 06:18:05 +08:00
|
|
|
/*
|
|
|
|
|
* dlm/gfs2 recovery coordination using dlm_recover callbacks
|
|
|
|
|
*
|
gfs2: Force withdraw to replay journals and wait for it to finish
When a node withdraws from a file system, it often leaves its journal
in an incomplete state. This is especially true when the withdraw is
caused by io errors writing to the journal. Before this patch, a
withdraw would try to write a "shutdown" record to the journal, tell
dlm it's done with the file system, and none of the other nodes
know about the problem. Later, when the problem is fixed and the
withdrawn node is rebooted, it would then discover that its own
journal was incomplete, and replay it. However, replaying it at this
point is almost guaranteed to introduce corruption because the other
nodes are likely to have used affected resource groups that appeared
in the journal since the time of the withdraw. Replaying the journal
later will overwrite any changes made, and not through any fault of
dlm, which was instructed during the withdraw to release those
resources.
This patch makes file system withdraws seen by the entire cluster.
Withdrawing nodes dequeue their journal glock to allow recovery.
The remaining nodes check all the journals to see if they are
clean or in need of replay. They try to replay dirty journals, but
only the journals of withdrawn nodes will be "not busy" and
therefore available for replay.
Until the journal replay is complete, no i/o related glocks may be
given out, to ensure that the replay does not cause the
aforementioned corruption: We cannot allow any journal replay to
overwrite blocks associated with a glock once it is held.
The "live" glock which is now used to signal when a withdraw
occurs. When a withdraw occurs, the node signals its withdraw by
dequeueing the "live" glock and trying to enqueue it in EX mode,
thus forcing the other nodes to all see a demote request, by way
of a "1CB" (one callback) try lock. The "live" glock is not
granted in EX; the callback is only just used to indicate a
withdraw has occurred.
Note that all nodes in the cluster must wait for the recovering
node to finish replaying the withdrawing node's journal before
continuing. To this end, it checks that the journals are clean
multiple times in a retry loop.
Also note that the withdraw function may be called from a wide
variety of situations, and therefore, we need to take extra
precautions to make sure pointers are valid before using them in
many circumstances.
We also need to take care when glocks decide to withdraw, since
the withdraw code now uses glocks.
Also, before this patch, if a process encountered an error and
decided to withdraw, if another process was already withdrawing,
the second withdraw would be silently ignored, which set it free
to unlock its glocks. That's correct behavior if the original
withdrawer encounters further errors down the road. But if
secondary waiters don't wait for the journal replay, unlocking
glocks will allow other nodes to use them, despite the fact that
the journal containing those blocks is being replayed. The
replay needs to finish before our glocks are released to other
nodes. IOW, secondary withdraws need to wait for the first
withdraw to finish.
For example, if an rgrp glock is unlocked by a process that didn't
wait for the first withdraw, a journal replay could introduce file
system corruption by replaying a rgrp block that has already been
granted to a different cluster node.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2020-01-29 03:23:45 +08:00
|
|
|
* 0. gfs2 checks for another cluster node withdraw, needing journal replay
|
2012-01-10 06:18:05 +08:00
|
|
|
* 1. dlm_controld sees lockspace members change
|
|
|
|
|
* 2. dlm_controld blocks dlm-kernel locking activity
|
|
|
|
|
* 3. dlm_controld within dlm-kernel notifies gfs2 (recover_prep)
|
|
|
|
|
* 4. dlm_controld starts and finishes its own user level recovery
|
|
|
|
|
* 5. dlm_controld starts dlm-kernel dlm_recoverd to do kernel recovery
|
|
|
|
|
* 6. dlm_recoverd notifies gfs2 of failed nodes (recover_slot)
|
|
|
|
|
* 7. dlm_recoverd does its own lock recovery
|
|
|
|
|
* 8. dlm_recoverd unblocks dlm-kernel locking activity
|
|
|
|
|
* 9. dlm_recoverd notifies gfs2 when done (recover_done with new generation)
|
|
|
|
|
* 10. gfs2_control updates control_lock lvb with new generation and jid bits
|
|
|
|
|
* 11. gfs2_control enqueues journals for gfs2_recover to recover (maybe none)
|
|
|
|
|
* 12. gfs2_recover dequeues and recovers journals of failed nodes
|
|
|
|
|
* 13. gfs2_recover provides recovery results to gfs2_control (recovery_result)
|
|
|
|
|
* 14. gfs2_control updates control_lock lvb jid bits for recovered journals
|
|
|
|
|
* 15. gfs2_control unblocks normal locking when all journals are recovered
|
|
|
|
|
*
|
|
|
|
|
* - failures during recovery
|
|
|
|
|
*
|
|
|
|
|
* recover_prep() may set BLOCK_LOCKS (step 3) again before gfs2_control
|
|
|
|
|
* clears BLOCK_LOCKS (step 15), e.g. another node fails while still
|
|
|
|
|
* recovering for a prior failure. gfs2_control needs a way to detect
|
|
|
|
|
* this so it can leave BLOCK_LOCKS set in step 15. This is managed using
|
|
|
|
|
* the recover_block and recover_start values.
|
|
|
|
|
*
|
|
|
|
|
* recover_done() provides a new lockspace generation number each time it
|
|
|
|
|
* is called (step 9). This generation number is saved as recover_start.
|
|
|
|
|
* When recover_prep() is called, it sets BLOCK_LOCKS and sets
|
|
|
|
|
* recover_block = recover_start. So, while recover_block is equal to
|
|
|
|
|
* recover_start, BLOCK_LOCKS should remain set. (recover_spin must
|
|
|
|
|
* be held around the BLOCK_LOCKS/recover_block/recover_start logic.)
|
|
|
|
|
*
|
|
|
|
|
* - more specific gfs2 steps in sequence above
|
|
|
|
|
*
|
|
|
|
|
* 3. recover_prep sets BLOCK_LOCKS and sets recover_block = recover_start
|
|
|
|
|
* 6. recover_slot records any failed jids (maybe none)
|
|
|
|
|
* 9. recover_done sets recover_start = new generation number
|
|
|
|
|
* 10. gfs2_control sets control_lock lvb = new gen + bits for failed jids
|
|
|
|
|
* 12. gfs2_recover does journal recoveries for failed jids identified above
|
|
|
|
|
* 14. gfs2_control clears control_lock lvb bits for recovered jids
|
|
|
|
|
* 15. gfs2_control checks if recover_block == recover_start (step 3 occured
|
|
|
|
|
* again) then do nothing, otherwise if recover_start > recover_block
|
|
|
|
|
* then clear BLOCK_LOCKS.
|
|
|
|
|
*
|
|
|
|
|
* - parallel recovery steps across all nodes
|
|
|
|
|
*
|
|
|
|
|
* All nodes attempt to update the control_lock lvb with the new generation
|
|
|
|
|
* number and jid bits, but only the first to get the control_lock EX will
|
|
|
|
|
* do so; others will see that it's already done (lvb already contains new
|
|
|
|
|
* generation number.)
|
|
|
|
|
*
|
|
|
|
|
* . All nodes get the same recover_prep/recover_slot/recover_done callbacks
|
|
|
|
|
* . All nodes attempt to set control_lock lvb gen + bits for the new gen
|
|
|
|
|
* . One node gets control_lock first and writes the lvb, others see it's done
|
|
|
|
|
* . All nodes attempt to recover jids for which they see control_lock bits set
|
|
|
|
|
* . One node succeeds for a jid, and that one clears the jid bit in the lvb
|
|
|
|
|
* . All nodes will eventually see all lvb bits clear and unblock locks
|
|
|
|
|
*
|
|
|
|
|
* - is there a problem with clearing an lvb bit that should be set
|
|
|
|
|
* and missing a journal recovery?
|
|
|
|
|
*
|
|
|
|
|
* 1. jid fails
|
|
|
|
|
* 2. lvb bit set for step 1
|
|
|
|
|
* 3. jid recovered for step 1
|
|
|
|
|
* 4. jid taken again (new mount)
|
|
|
|
|
* 5. jid fails (for step 4)
|
|
|
|
|
* 6. lvb bit set for step 5 (will already be set)
|
|
|
|
|
* 7. lvb bit cleared for step 3
|
|
|
|
|
*
|
|
|
|
|
* This is not a problem because the failure in step 5 does not
|
|
|
|
|
* require recovery, because the mount in step 4 could not have
|
|
|
|
|
* progressed far enough to unblock locks and access the fs. The
|
|
|
|
|
* control_mount() function waits for all recoveries to be complete
|
|
|
|
|
* for the latest lockspace generation before ever unblocking locks
|
|
|
|
|
* and returning. The mount in step 4 waits until the recovery in
|
|
|
|
|
* step 1 is done.
|
|
|
|
|
*
|
|
|
|
|
* - special case of first mounter: first node to mount the fs
|
|
|
|
|
*
|
|
|
|
|
* The first node to mount a gfs2 fs needs to check all the journals
|
|
|
|
|
* and recover any that need recovery before other nodes are allowed
|
|
|
|
|
* to mount the fs. (Others may begin mounting, but they must wait
|
|
|
|
|
* for the first mounter to be done before taking locks on the fs
|
|
|
|
|
* or accessing the fs.) This has two parts:
|
|
|
|
|
*
|
|
|
|
|
* 1. The mounted_lock tells a node it's the first to mount the fs.
|
|
|
|
|
* Each node holds the mounted_lock in PR while it's mounted.
|
|
|
|
|
* Each node tries to acquire the mounted_lock in EX when it mounts.
|
|
|
|
|
* If a node is granted the mounted_lock EX it means there are no
|
|
|
|
|
* other mounted nodes (no PR locks exist), and it is the first mounter.
|
|
|
|
|
* The mounted_lock is demoted to PR when first recovery is done, so
|
|
|
|
|
* others will fail to get an EX lock, but will get a PR lock.
|
|
|
|
|
*
|
|
|
|
|
* 2. The control_lock blocks others in control_mount() while the first
|
|
|
|
|
* mounter is doing first mount recovery of all journals.
|
|
|
|
|
* A mounting node needs to acquire control_lock in EX mode before
|
|
|
|
|
* it can proceed. The first mounter holds control_lock in EX while doing
|
|
|
|
|
* the first mount recovery, blocking mounts from other nodes, then demotes
|
|
|
|
|
* control_lock to NL when it's done (others_may_mount/first_done),
|
|
|
|
|
* allowing other nodes to continue mounting.
|
|
|
|
|
*
|
|
|
|
|
* first mounter:
|
|
|
|
|
* control_lock EX/NOQUEUE success
|
|
|
|
|
* mounted_lock EX/NOQUEUE success (no other PR, so no other mounters)
|
|
|
|
|
* set first=1
|
|
|
|
|
* do first mounter recovery
|
|
|
|
|
* mounted_lock EX->PR
|
|
|
|
|
* control_lock EX->NL, write lvb generation
|
|
|
|
|
*
|
|
|
|
|
* other mounter:
|
|
|
|
|
* control_lock EX/NOQUEUE success (if fail -EAGAIN, retry)
|
|
|
|
|
* mounted_lock EX/NOQUEUE fail -EAGAIN (expected due to other mounters PR)
|
|
|
|
|
* mounted_lock PR/NOQUEUE success
|
|
|
|
|
* read lvb generation
|
|
|
|
|
* control_lock EX->NL
|
|
|
|
|
* set first=0
|
|
|
|
|
*
|
|
|
|
|
* - mount during recovery
|
|
|
|
|
*
|
|
|
|
|
* If a node mounts while others are doing recovery (not first mounter),
|
|
|
|
|
* the mounting node will get its initial recover_done() callback without
|
|
|
|
|
* having seen any previous failures/callbacks.
|
|
|
|
|
*
|
|
|
|
|
* It must wait for all recoveries preceding its mount to be finished
|
|
|
|
|
* before it unblocks locks. It does this by repeating the "other mounter"
|
|
|
|
|
* steps above until the lvb generation number is >= its mount generation
|
|
|
|
|
* number (from initial recover_done) and all lvb bits are clear.
|
|
|
|
|
*
|
|
|
|
|
* - control_lock lvb format
|
|
|
|
|
*
|
|
|
|
|
* 4 bytes generation number: the latest dlm lockspace generation number
|
|
|
|
|
* from recover_done callback. Indicates the jid bitmap has been updated
|
|
|
|
|
* to reflect all slot failures through that generation.
|
|
|
|
|
* 4 bytes unused.
|
|
|
|
|
* GDLM_LVB_SIZE-8 bytes of jid bit map. If bit N is set, it indicates
|
|
|
|
|
* that jid N needs recovery.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#define JID_BITMAP_OFFSET 8 /* 4 byte generation number + 4 byte unused */
|
|
|
|
|
|
|
|
|
|
static void control_lvb_read(struct lm_lockstruct *ls, uint32_t *lvb_gen,
|
|
|
|
|
char *lvb_bits)
|
|
|
|
|
{
|
2013-06-03 07:53:40 +08:00
|
|
|
__le32 gen;
|
2012-01-10 06:18:05 +08:00
|
|
|
memcpy(lvb_bits, ls->ls_control_lvb, GDLM_LVB_SIZE);
|
2013-06-03 07:53:40 +08:00
|
|
|
memcpy(&gen, lvb_bits, sizeof(__le32));
|
2012-01-10 06:18:05 +08:00
|
|
|
*lvb_gen = le32_to_cpu(gen);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void control_lvb_write(struct lm_lockstruct *ls, uint32_t lvb_gen,
|
|
|
|
|
char *lvb_bits)
|
|
|
|
|
{
|
2013-06-03 07:53:40 +08:00
|
|
|
__le32 gen;
|
2012-01-10 06:18:05 +08:00
|
|
|
memcpy(ls->ls_control_lvb, lvb_bits, GDLM_LVB_SIZE);
|
|
|
|
|
gen = cpu_to_le32(lvb_gen);
|
2013-06-03 07:53:40 +08:00
|
|
|
memcpy(ls->ls_control_lvb, &gen, sizeof(__le32));
|
2012-01-10 06:18:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int all_jid_bits_clear(char *lvb)
|
|
|
|
|
{
|
2013-03-07 22:42:52 +08:00
|
|
|
return !memchr_inv(lvb + JID_BITMAP_OFFSET, 0,
|
|
|
|
|
GDLM_LVB_SIZE - JID_BITMAP_OFFSET);
|
2012-01-10 06:18:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void sync_wait_cb(void *arg)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = arg;
|
|
|
|
|
complete(&ls->ls_sync_wait);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int sync_unlock(struct gfs2_sbd *sdp, struct dlm_lksb *lksb, char *name)
|
2009-01-12 18:43:39 +08:00
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
int error;
|
|
|
|
|
|
2012-01-10 06:18:05 +08:00
|
|
|
error = dlm_unlock(ls->ls_dlm, lksb->sb_lkid, 0, lksb, ls);
|
|
|
|
|
if (error) {
|
|
|
|
|
fs_err(sdp, "%s lkid %x error %d\n",
|
|
|
|
|
name, lksb->sb_lkid, error);
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
wait_for_completion(&ls->ls_sync_wait);
|
|
|
|
|
|
|
|
|
|
if (lksb->sb_status != -DLM_EUNLOCK) {
|
|
|
|
|
fs_err(sdp, "%s lkid %x status %d\n",
|
|
|
|
|
name, lksb->sb_lkid, lksb->sb_status);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int sync_lock(struct gfs2_sbd *sdp, int mode, uint32_t flags,
|
|
|
|
|
unsigned int num, struct dlm_lksb *lksb, char *name)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
char strname[GDLM_STRNAME_BYTES];
|
|
|
|
|
int error, status;
|
|
|
|
|
|
|
|
|
|
memset(strname, 0, GDLM_STRNAME_BYTES);
|
|
|
|
|
snprintf(strname, GDLM_STRNAME_BYTES, "%8x%16x", LM_TYPE_NONDISK, num);
|
|
|
|
|
|
|
|
|
|
error = dlm_lock(ls->ls_dlm, mode, lksb, flags,
|
|
|
|
|
strname, GDLM_STRNAME_BYTES - 1,
|
|
|
|
|
0, sync_wait_cb, ls, NULL);
|
|
|
|
|
if (error) {
|
|
|
|
|
fs_err(sdp, "%s lkid %x flags %x mode %d error %d\n",
|
|
|
|
|
name, lksb->sb_lkid, flags, mode, error);
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
wait_for_completion(&ls->ls_sync_wait);
|
|
|
|
|
|
|
|
|
|
status = lksb->sb_status;
|
|
|
|
|
|
|
|
|
|
if (status && status != -EAGAIN) {
|
|
|
|
|
fs_err(sdp, "%s lkid %x flags %x mode %d status %d\n",
|
|
|
|
|
name, lksb->sb_lkid, flags, mode, status);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return status;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mounted_unlock(struct gfs2_sbd *sdp)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
return sync_unlock(sdp, &ls->ls_mounted_lksb, "mounted_lock");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int mounted_lock(struct gfs2_sbd *sdp, int mode, uint32_t flags)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
return sync_lock(sdp, mode, flags, GFS2_MOUNTED_LOCK,
|
|
|
|
|
&ls->ls_mounted_lksb, "mounted_lock");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int control_unlock(struct gfs2_sbd *sdp)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
return sync_unlock(sdp, &ls->ls_control_lksb, "control_lock");
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int control_lock(struct gfs2_sbd *sdp, int mode, uint32_t flags)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
return sync_lock(sdp, mode, flags, GFS2_CONTROL_LOCK,
|
|
|
|
|
&ls->ls_control_lksb, "control_lock");
|
|
|
|
|
}
|
|
|
|
|
|
gfs2: Force withdraw to replay journals and wait for it to finish
When a node withdraws from a file system, it often leaves its journal
in an incomplete state. This is especially true when the withdraw is
caused by io errors writing to the journal. Before this patch, a
withdraw would try to write a "shutdown" record to the journal, tell
dlm it's done with the file system, and none of the other nodes
know about the problem. Later, when the problem is fixed and the
withdrawn node is rebooted, it would then discover that its own
journal was incomplete, and replay it. However, replaying it at this
point is almost guaranteed to introduce corruption because the other
nodes are likely to have used affected resource groups that appeared
in the journal since the time of the withdraw. Replaying the journal
later will overwrite any changes made, and not through any fault of
dlm, which was instructed during the withdraw to release those
resources.
This patch makes file system withdraws seen by the entire cluster.
Withdrawing nodes dequeue their journal glock to allow recovery.
The remaining nodes check all the journals to see if they are
clean or in need of replay. They try to replay dirty journals, but
only the journals of withdrawn nodes will be "not busy" and
therefore available for replay.
Until the journal replay is complete, no i/o related glocks may be
given out, to ensure that the replay does not cause the
aforementioned corruption: We cannot allow any journal replay to
overwrite blocks associated with a glock once it is held.
The "live" glock which is now used to signal when a withdraw
occurs. When a withdraw occurs, the node signals its withdraw by
dequeueing the "live" glock and trying to enqueue it in EX mode,
thus forcing the other nodes to all see a demote request, by way
of a "1CB" (one callback) try lock. The "live" glock is not
granted in EX; the callback is only just used to indicate a
withdraw has occurred.
Note that all nodes in the cluster must wait for the recovering
node to finish replaying the withdrawing node's journal before
continuing. To this end, it checks that the journals are clean
multiple times in a retry loop.
Also note that the withdraw function may be called from a wide
variety of situations, and therefore, we need to take extra
precautions to make sure pointers are valid before using them in
many circumstances.
We also need to take care when glocks decide to withdraw, since
the withdraw code now uses glocks.
Also, before this patch, if a process encountered an error and
decided to withdraw, if another process was already withdrawing,
the second withdraw would be silently ignored, which set it free
to unlock its glocks. That's correct behavior if the original
withdrawer encounters further errors down the road. But if
secondary waiters don't wait for the journal replay, unlocking
glocks will allow other nodes to use them, despite the fact that
the journal containing those blocks is being replayed. The
replay needs to finish before our glocks are released to other
nodes. IOW, secondary withdraws need to wait for the first
withdraw to finish.
For example, if an rgrp glock is unlocked by a process that didn't
wait for the first withdraw, a journal replay could introduce file
system corruption by replaying a rgrp block that has already been
granted to a different cluster node.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2020-01-29 03:23:45 +08:00
|
|
|
/**
|
|
|
|
|
* remote_withdraw - react to a node withdrawing from the file system
|
|
|
|
|
* @sdp: The superblock
|
|
|
|
|
*/
|
|
|
|
|
static void remote_withdraw(struct gfs2_sbd *sdp)
|
|
|
|
|
{
|
|
|
|
|
struct gfs2_jdesc *jd;
|
|
|
|
|
int ret = 0, count = 0;
|
|
|
|
|
|
|
|
|
|
list_for_each_entry(jd, &sdp->sd_jindex_list, jd_list) {
|
|
|
|
|
if (jd->jd_jid == sdp->sd_lockstruct.ls_jid)
|
|
|
|
|
continue;
|
|
|
|
|
ret = gfs2_recover_journal(jd, true);
|
|
|
|
|
if (ret)
|
|
|
|
|
break;
|
|
|
|
|
count++;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* Now drop the additional reference we acquired */
|
|
|
|
|
fs_err(sdp, "Journals checked: %d, ret = %d.\n", count, ret);
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-10 06:18:05 +08:00
|
|
|
static void gfs2_control_func(struct work_struct *work)
|
|
|
|
|
{
|
|
|
|
|
struct gfs2_sbd *sdp = container_of(work, struct gfs2_sbd, sd_control_work.work);
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
uint32_t block_gen, start_gen, lvb_gen, flags;
|
|
|
|
|
int recover_set = 0;
|
|
|
|
|
int write_lvb = 0;
|
|
|
|
|
int recover_size;
|
|
|
|
|
int i, error;
|
|
|
|
|
|
gfs2: Force withdraw to replay journals and wait for it to finish
When a node withdraws from a file system, it often leaves its journal
in an incomplete state. This is especially true when the withdraw is
caused by io errors writing to the journal. Before this patch, a
withdraw would try to write a "shutdown" record to the journal, tell
dlm it's done with the file system, and none of the other nodes
know about the problem. Later, when the problem is fixed and the
withdrawn node is rebooted, it would then discover that its own
journal was incomplete, and replay it. However, replaying it at this
point is almost guaranteed to introduce corruption because the other
nodes are likely to have used affected resource groups that appeared
in the journal since the time of the withdraw. Replaying the journal
later will overwrite any changes made, and not through any fault of
dlm, which was instructed during the withdraw to release those
resources.
This patch makes file system withdraws seen by the entire cluster.
Withdrawing nodes dequeue their journal glock to allow recovery.
The remaining nodes check all the journals to see if they are
clean or in need of replay. They try to replay dirty journals, but
only the journals of withdrawn nodes will be "not busy" and
therefore available for replay.
Until the journal replay is complete, no i/o related glocks may be
given out, to ensure that the replay does not cause the
aforementioned corruption: We cannot allow any journal replay to
overwrite blocks associated with a glock once it is held.
The "live" glock which is now used to signal when a withdraw
occurs. When a withdraw occurs, the node signals its withdraw by
dequeueing the "live" glock and trying to enqueue it in EX mode,
thus forcing the other nodes to all see a demote request, by way
of a "1CB" (one callback) try lock. The "live" glock is not
granted in EX; the callback is only just used to indicate a
withdraw has occurred.
Note that all nodes in the cluster must wait for the recovering
node to finish replaying the withdrawing node's journal before
continuing. To this end, it checks that the journals are clean
multiple times in a retry loop.
Also note that the withdraw function may be called from a wide
variety of situations, and therefore, we need to take extra
precautions to make sure pointers are valid before using them in
many circumstances.
We also need to take care when glocks decide to withdraw, since
the withdraw code now uses glocks.
Also, before this patch, if a process encountered an error and
decided to withdraw, if another process was already withdrawing,
the second withdraw would be silently ignored, which set it free
to unlock its glocks. That's correct behavior if the original
withdrawer encounters further errors down the road. But if
secondary waiters don't wait for the journal replay, unlocking
glocks will allow other nodes to use them, despite the fact that
the journal containing those blocks is being replayed. The
replay needs to finish before our glocks are released to other
nodes. IOW, secondary withdraws need to wait for the first
withdraw to finish.
For example, if an rgrp glock is unlocked by a process that didn't
wait for the first withdraw, a journal replay could introduce file
system corruption by replaying a rgrp block that has already been
granted to a different cluster node.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2020-01-29 03:23:45 +08:00
|
|
|
/* First check for other nodes that may have done a withdraw. */
|
|
|
|
|
if (test_bit(SDF_REMOTE_WITHDRAW, &sdp->sd_flags)) {
|
|
|
|
|
remote_withdraw(sdp);
|
|
|
|
|
clear_bit(SDF_REMOTE_WITHDRAW, &sdp->sd_flags);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-10 06:18:05 +08:00
|
|
|
spin_lock(&ls->ls_recover_spin);
|
|
|
|
|
/*
|
|
|
|
|
* No MOUNT_DONE means we're still mounting; control_mount()
|
|
|
|
|
* will set this flag, after which this thread will take over
|
|
|
|
|
* all further clearing of BLOCK_LOCKS.
|
|
|
|
|
*
|
|
|
|
|
* FIRST_MOUNT means this node is doing first mounter recovery,
|
|
|
|
|
* for which recovery control is handled by
|
|
|
|
|
* control_mount()/control_first_done(), not this thread.
|
|
|
|
|
*/
|
|
|
|
|
if (!test_bit(DFL_MOUNT_DONE, &ls->ls_recover_flags) ||
|
|
|
|
|
test_bit(DFL_FIRST_MOUNT, &ls->ls_recover_flags)) {
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
block_gen = ls->ls_recover_block;
|
|
|
|
|
start_gen = ls->ls_recover_start;
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Equal block_gen and start_gen implies we are between
|
|
|
|
|
* recover_prep and recover_done callbacks, which means
|
|
|
|
|
* dlm recovery is in progress and dlm locking is blocked.
|
|
|
|
|
* There's no point trying to do any work until recover_done.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
if (block_gen == start_gen)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Propagate recover_submit[] and recover_result[] to lvb:
|
|
|
|
|
* dlm_recoverd adds to recover_submit[] jids needing recovery
|
|
|
|
|
* gfs2_recover adds to recover_result[] journal recovery results
|
|
|
|
|
*
|
|
|
|
|
* set lvb bit for jids in recover_submit[] if the lvb has not
|
|
|
|
|
* yet been updated for the generation of the failure
|
|
|
|
|
*
|
|
|
|
|
* clear lvb bit for jids in recover_result[] if the result of
|
|
|
|
|
* the journal recovery is SUCCESS
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
error = control_lock(sdp, DLM_LOCK_EX, DLM_LKF_CONVERT|DLM_LKF_VALBLK);
|
|
|
|
|
if (error) {
|
|
|
|
|
fs_err(sdp, "control lock EX error %d\n", error);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
2013-03-06 05:01:47 +08:00
|
|
|
control_lvb_read(ls, &lvb_gen, ls->ls_lvb_bits);
|
2012-01-10 06:18:05 +08:00
|
|
|
|
|
|
|
|
spin_lock(&ls->ls_recover_spin);
|
|
|
|
|
if (block_gen != ls->ls_recover_block ||
|
|
|
|
|
start_gen != ls->ls_recover_start) {
|
|
|
|
|
fs_info(sdp, "recover generation %u block1 %u %u\n",
|
|
|
|
|
start_gen, block_gen, ls->ls_recover_block);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
control_lock(sdp, DLM_LOCK_NL, DLM_LKF_CONVERT);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
recover_size = ls->ls_recover_size;
|
|
|
|
|
|
|
|
|
|
if (lvb_gen <= start_gen) {
|
|
|
|
|
/*
|
|
|
|
|
* Clear lvb bits for jids we've successfully recovered.
|
|
|
|
|
* Because all nodes attempt to recover failed journals,
|
|
|
|
|
* a journal can be recovered multiple times successfully
|
|
|
|
|
* in succession. Only the first will really do recovery,
|
|
|
|
|
* the others find it clean, but still report a successful
|
|
|
|
|
* recovery. So, another node may have already recovered
|
|
|
|
|
* the jid and cleared the lvb bit for it.
|
|
|
|
|
*/
|
|
|
|
|
for (i = 0; i < recover_size; i++) {
|
|
|
|
|
if (ls->ls_recover_result[i] != LM_RD_SUCCESS)
|
|
|
|
|
continue;
|
|
|
|
|
|
|
|
|
|
ls->ls_recover_result[i] = 0;
|
|
|
|
|
|
2013-03-06 05:01:47 +08:00
|
|
|
if (!test_bit_le(i, ls->ls_lvb_bits + JID_BITMAP_OFFSET))
|
2012-01-10 06:18:05 +08:00
|
|
|
continue;
|
|
|
|
|
|
2013-03-06 05:01:47 +08:00
|
|
|
__clear_bit_le(i, ls->ls_lvb_bits + JID_BITMAP_OFFSET);
|
2012-01-10 06:18:05 +08:00
|
|
|
write_lvb = 1;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (lvb_gen == start_gen) {
|
|
|
|
|
/*
|
|
|
|
|
* Failed slots before start_gen are already set in lvb.
|
|
|
|
|
*/
|
|
|
|
|
for (i = 0; i < recover_size; i++) {
|
|
|
|
|
if (!ls->ls_recover_submit[i])
|
|
|
|
|
continue;
|
|
|
|
|
if (ls->ls_recover_submit[i] < lvb_gen)
|
|
|
|
|
ls->ls_recover_submit[i] = 0;
|
|
|
|
|
}
|
|
|
|
|
} else if (lvb_gen < start_gen) {
|
|
|
|
|
/*
|
|
|
|
|
* Failed slots before start_gen are not yet set in lvb.
|
|
|
|
|
*/
|
|
|
|
|
for (i = 0; i < recover_size; i++) {
|
|
|
|
|
if (!ls->ls_recover_submit[i])
|
|
|
|
|
continue;
|
|
|
|
|
if (ls->ls_recover_submit[i] < start_gen) {
|
|
|
|
|
ls->ls_recover_submit[i] = 0;
|
2013-03-06 05:01:47 +08:00
|
|
|
__set_bit_le(i, ls->ls_lvb_bits + JID_BITMAP_OFFSET);
|
2012-01-10 06:18:05 +08:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
/* even if there are no bits to set, we need to write the
|
|
|
|
|
latest generation to the lvb */
|
|
|
|
|
write_lvb = 1;
|
|
|
|
|
} else {
|
|
|
|
|
/*
|
|
|
|
|
* we should be getting a recover_done() for lvb_gen soon
|
|
|
|
|
*/
|
|
|
|
|
}
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
|
|
|
|
|
if (write_lvb) {
|
2013-03-06 05:01:47 +08:00
|
|
|
control_lvb_write(ls, start_gen, ls->ls_lvb_bits);
|
2012-01-10 06:18:05 +08:00
|
|
|
flags = DLM_LKF_CONVERT | DLM_LKF_VALBLK;
|
|
|
|
|
} else {
|
|
|
|
|
flags = DLM_LKF_CONVERT;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
error = control_lock(sdp, DLM_LOCK_NL, flags);
|
|
|
|
|
if (error) {
|
|
|
|
|
fs_err(sdp, "control lock NL error %d\n", error);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Everyone will see jid bits set in the lvb, run gfs2_recover_set(),
|
|
|
|
|
* and clear a jid bit in the lvb if the recovery is a success.
|
|
|
|
|
* Eventually all journals will be recovered, all jid bits will
|
|
|
|
|
* be cleared in the lvb, and everyone will clear BLOCK_LOCKS.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < recover_size; i++) {
|
2013-03-06 05:01:47 +08:00
|
|
|
if (test_bit_le(i, ls->ls_lvb_bits + JID_BITMAP_OFFSET)) {
|
2012-01-10 06:18:05 +08:00
|
|
|
fs_info(sdp, "recover generation %u jid %d\n",
|
|
|
|
|
start_gen, i);
|
|
|
|
|
gfs2_recover_set(sdp, i);
|
|
|
|
|
recover_set++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (recover_set)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* No more jid bits set in lvb, all recovery is done, unblock locks
|
|
|
|
|
* (unless a new recover_prep callback has occured blocking locks
|
|
|
|
|
* again while working above)
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
spin_lock(&ls->ls_recover_spin);
|
|
|
|
|
if (ls->ls_recover_block == block_gen &&
|
|
|
|
|
ls->ls_recover_start == start_gen) {
|
|
|
|
|
clear_bit(DFL_BLOCK_LOCKS, &ls->ls_recover_flags);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
fs_info(sdp, "recover generation %u done\n", start_gen);
|
|
|
|
|
gfs2_glock_thaw(sdp);
|
|
|
|
|
} else {
|
|
|
|
|
fs_info(sdp, "recover generation %u block2 %u %u\n",
|
|
|
|
|
start_gen, block_gen, ls->ls_recover_block);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int control_mount(struct gfs2_sbd *sdp)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
uint32_t start_gen, block_gen, mount_gen, lvb_gen;
|
|
|
|
|
int mounted_mode;
|
|
|
|
|
int retries = 0;
|
|
|
|
|
int error;
|
|
|
|
|
|
|
|
|
|
memset(&ls->ls_mounted_lksb, 0, sizeof(struct dlm_lksb));
|
|
|
|
|
memset(&ls->ls_control_lksb, 0, sizeof(struct dlm_lksb));
|
|
|
|
|
memset(&ls->ls_control_lvb, 0, GDLM_LVB_SIZE);
|
|
|
|
|
ls->ls_control_lksb.sb_lvbptr = ls->ls_control_lvb;
|
|
|
|
|
init_completion(&ls->ls_sync_wait);
|
|
|
|
|
|
|
|
|
|
set_bit(DFL_BLOCK_LOCKS, &ls->ls_recover_flags);
|
|
|
|
|
|
|
|
|
|
error = control_lock(sdp, DLM_LOCK_NL, DLM_LKF_VALBLK);
|
|
|
|
|
if (error) {
|
|
|
|
|
fs_err(sdp, "control_mount control_lock NL error %d\n", error);
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
error = mounted_lock(sdp, DLM_LOCK_NL, 0);
|
|
|
|
|
if (error) {
|
|
|
|
|
fs_err(sdp, "control_mount mounted_lock NL error %d\n", error);
|
|
|
|
|
control_unlock(sdp);
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
mounted_mode = DLM_LOCK_NL;
|
|
|
|
|
|
|
|
|
|
restart:
|
|
|
|
|
if (retries++ && signal_pending(current)) {
|
|
|
|
|
error = -EINTR;
|
|
|
|
|
goto fail;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We always start with both locks in NL. control_lock is
|
|
|
|
|
* demoted to NL below so we don't need to do it here.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
if (mounted_mode != DLM_LOCK_NL) {
|
|
|
|
|
error = mounted_lock(sdp, DLM_LOCK_NL, DLM_LKF_CONVERT);
|
|
|
|
|
if (error)
|
|
|
|
|
goto fail;
|
|
|
|
|
mounted_mode = DLM_LOCK_NL;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Other nodes need to do some work in dlm recovery and gfs2_control
|
|
|
|
|
* before the recover_done and control_lock will be ready for us below.
|
|
|
|
|
* A delay here is not required but often avoids having to retry.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
msleep_interruptible(500);
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Acquire control_lock in EX and mounted_lock in either EX or PR.
|
|
|
|
|
* control_lock lvb keeps track of any pending journal recoveries.
|
|
|
|
|
* mounted_lock indicates if any other nodes have the fs mounted.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
error = control_lock(sdp, DLM_LOCK_EX, DLM_LKF_CONVERT|DLM_LKF_NOQUEUE|DLM_LKF_VALBLK);
|
|
|
|
|
if (error == -EAGAIN) {
|
|
|
|
|
goto restart;
|
|
|
|
|
} else if (error) {
|
|
|
|
|
fs_err(sdp, "control_mount control_lock EX error %d\n", error);
|
|
|
|
|
goto fail;
|
|
|
|
|
}
|
|
|
|
|
|
GFS2: Fix recovery issues for spectators
This patch fixes a couple problems dealing with spectators who
remain with gfs2 mounts after the last non-spectator node fails.
Before this patch, spectator mounts would try to acquire the dlm's
mounted lock EX as part of its normal recovery sequence.
The mounted lock is only used to determine whether the node is
the first mounter, the first node to mount the file system, for
the purposes of file system recovery and journal replay.
It's not necessary for spectators: they should never do journal
recovery. If they acquire the lock it will prevent another "real"
first-mounter from acquiring the lock in EX mode, which means it
also cannot do journal recovery because it doesn't think it's the
first node to mount the file system.
This patch checks if the mounter is a spectator, and if so, avoids
grabbing the mounted lock. This allows a secondary mounter who is
really the first non-spectator mounter, to do journal recovery:
since the spectator doesn't acquire the lock, it can grab it in
EX mode, and therefore consider itself to be the first mounter
both as a "real" first mount, and as a first-real-after-spectator.
Note that the control lock still needs to be taken in PR mode
in order to fetch the lvb value so it has the current status of
all journal's recovery. This is used as it is today by a first
mounter to replay the journals. For spectators, it's merely
used to fetch the status bits. All recovery is bypassed and the
node waits until recovery is completed by a non-spectator node.
I also improved the cryptic message given by control_mount when
a spectator is waiting for a non-spectator to perform recovery.
It also fixes a problem in gfs2_recover_set whereby spectators
were never queueing recovery work for their own journal.
They cannot do recovery themselves, but they still need to queue
the work so they can check the recovery bits and clear the
DFL_BLOCK_LOCKS bit once the recovery happens on another node.
When the work queue runs on a spectator, it bypasses most of the
work so it won't print a bunch of annoying messages. All it will
print is a bunch of messages that look like this until recovery
completes on the non-spectator node:
GFS2: fsid=mycluster:scratch.s: recover generation 3 jid 0
GFS2: fsid=mycluster:scratch.s: recover jid 0 result busy
These continue every 1.5 seconds until the recovery is done by
the non-spectator, at which time it says:
GFS2: fsid=mycluster:scratch.s: recover generation 4 done
Then it proceeds with its mount.
If the file system is mounted in spectator node and the last
remaining non-spectator is fenced, any IO to the file system is
blocked by dlm and the spectator waits until recovery is
performed by a non-spectator.
If a spectator tries to mount the file system before any
non-spectators, it blocks and repeatedly gives this kernel
message:
GFS2: fsid=mycluster:scratch: Recovery is required. Waiting for a non-spectator to mount.
GFS2: fsid=mycluster:scratch: Recovery is required. Waiting for a non-spectator to mount.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2018-07-06 03:40:46 +08:00
|
|
|
/**
|
|
|
|
|
* If we're a spectator, we don't want to take the lock in EX because
|
|
|
|
|
* we cannot do the first-mount responsibility it implies: recovery.
|
|
|
|
|
*/
|
|
|
|
|
if (sdp->sd_args.ar_spectator)
|
|
|
|
|
goto locks_done;
|
|
|
|
|
|
2012-01-10 06:18:05 +08:00
|
|
|
error = mounted_lock(sdp, DLM_LOCK_EX, DLM_LKF_CONVERT|DLM_LKF_NOQUEUE);
|
|
|
|
|
if (!error) {
|
|
|
|
|
mounted_mode = DLM_LOCK_EX;
|
|
|
|
|
goto locks_done;
|
|
|
|
|
} else if (error != -EAGAIN) {
|
|
|
|
|
fs_err(sdp, "control_mount mounted_lock EX error %d\n", error);
|
|
|
|
|
goto fail;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
error = mounted_lock(sdp, DLM_LOCK_PR, DLM_LKF_CONVERT|DLM_LKF_NOQUEUE);
|
|
|
|
|
if (!error) {
|
|
|
|
|
mounted_mode = DLM_LOCK_PR;
|
|
|
|
|
goto locks_done;
|
|
|
|
|
} else {
|
|
|
|
|
/* not even -EAGAIN should happen here */
|
|
|
|
|
fs_err(sdp, "control_mount mounted_lock PR error %d\n", error);
|
|
|
|
|
goto fail;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
locks_done:
|
|
|
|
|
/*
|
|
|
|
|
* If we got both locks above in EX, then we're the first mounter.
|
|
|
|
|
* If not, then we need to wait for the control_lock lvb to be
|
|
|
|
|
* updated by other mounted nodes to reflect our mount generation.
|
|
|
|
|
*
|
|
|
|
|
* In simple first mounter cases, first mounter will see zero lvb_gen,
|
|
|
|
|
* but in cases where all existing nodes leave/fail before mounting
|
|
|
|
|
* nodes finish control_mount, then all nodes will be mounting and
|
|
|
|
|
* lvb_gen will be non-zero.
|
|
|
|
|
*/
|
|
|
|
|
|
2013-03-06 05:01:47 +08:00
|
|
|
control_lvb_read(ls, &lvb_gen, ls->ls_lvb_bits);
|
2012-01-10 06:18:05 +08:00
|
|
|
|
|
|
|
|
if (lvb_gen == 0xFFFFFFFF) {
|
|
|
|
|
/* special value to force mount attempts to fail */
|
|
|
|
|
fs_err(sdp, "control_mount control_lock disabled\n");
|
|
|
|
|
error = -EINVAL;
|
|
|
|
|
goto fail;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (mounted_mode == DLM_LOCK_EX) {
|
|
|
|
|
/* first mounter, keep both EX while doing first recovery */
|
|
|
|
|
spin_lock(&ls->ls_recover_spin);
|
|
|
|
|
clear_bit(DFL_BLOCK_LOCKS, &ls->ls_recover_flags);
|
|
|
|
|
set_bit(DFL_MOUNT_DONE, &ls->ls_recover_flags);
|
|
|
|
|
set_bit(DFL_FIRST_MOUNT, &ls->ls_recover_flags);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
fs_info(sdp, "first mounter control generation %u\n", lvb_gen);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
error = control_lock(sdp, DLM_LOCK_NL, DLM_LKF_CONVERT);
|
|
|
|
|
if (error)
|
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* We are not first mounter, now we need to wait for the control_lock
|
|
|
|
|
* lvb generation to be >= the generation from our first recover_done
|
|
|
|
|
* and all lvb bits to be clear (no pending journal recoveries.)
|
|
|
|
|
*/
|
|
|
|
|
|
2013-03-06 05:01:47 +08:00
|
|
|
if (!all_jid_bits_clear(ls->ls_lvb_bits)) {
|
2012-01-10 06:18:05 +08:00
|
|
|
/* journals need recovery, wait until all are clear */
|
|
|
|
|
fs_info(sdp, "control_mount wait for journal recovery\n");
|
|
|
|
|
goto restart;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
spin_lock(&ls->ls_recover_spin);
|
|
|
|
|
block_gen = ls->ls_recover_block;
|
|
|
|
|
start_gen = ls->ls_recover_start;
|
|
|
|
|
mount_gen = ls->ls_recover_mount;
|
|
|
|
|
|
|
|
|
|
if (lvb_gen < mount_gen) {
|
|
|
|
|
/* wait for mounted nodes to update control_lock lvb to our
|
|
|
|
|
generation, which might include new recovery bits set */
|
GFS2: Fix recovery issues for spectators
This patch fixes a couple problems dealing with spectators who
remain with gfs2 mounts after the last non-spectator node fails.
Before this patch, spectator mounts would try to acquire the dlm's
mounted lock EX as part of its normal recovery sequence.
The mounted lock is only used to determine whether the node is
the first mounter, the first node to mount the file system, for
the purposes of file system recovery and journal replay.
It's not necessary for spectators: they should never do journal
recovery. If they acquire the lock it will prevent another "real"
first-mounter from acquiring the lock in EX mode, which means it
also cannot do journal recovery because it doesn't think it's the
first node to mount the file system.
This patch checks if the mounter is a spectator, and if so, avoids
grabbing the mounted lock. This allows a secondary mounter who is
really the first non-spectator mounter, to do journal recovery:
since the spectator doesn't acquire the lock, it can grab it in
EX mode, and therefore consider itself to be the first mounter
both as a "real" first mount, and as a first-real-after-spectator.
Note that the control lock still needs to be taken in PR mode
in order to fetch the lvb value so it has the current status of
all journal's recovery. This is used as it is today by a first
mounter to replay the journals. For spectators, it's merely
used to fetch the status bits. All recovery is bypassed and the
node waits until recovery is completed by a non-spectator node.
I also improved the cryptic message given by control_mount when
a spectator is waiting for a non-spectator to perform recovery.
It also fixes a problem in gfs2_recover_set whereby spectators
were never queueing recovery work for their own journal.
They cannot do recovery themselves, but they still need to queue
the work so they can check the recovery bits and clear the
DFL_BLOCK_LOCKS bit once the recovery happens on another node.
When the work queue runs on a spectator, it bypasses most of the
work so it won't print a bunch of annoying messages. All it will
print is a bunch of messages that look like this until recovery
completes on the non-spectator node:
GFS2: fsid=mycluster:scratch.s: recover generation 3 jid 0
GFS2: fsid=mycluster:scratch.s: recover jid 0 result busy
These continue every 1.5 seconds until the recovery is done by
the non-spectator, at which time it says:
GFS2: fsid=mycluster:scratch.s: recover generation 4 done
Then it proceeds with its mount.
If the file system is mounted in spectator node and the last
remaining non-spectator is fenced, any IO to the file system is
blocked by dlm and the spectator waits until recovery is
performed by a non-spectator.
If a spectator tries to mount the file system before any
non-spectators, it blocks and repeatedly gives this kernel
message:
GFS2: fsid=mycluster:scratch: Recovery is required. Waiting for a non-spectator to mount.
GFS2: fsid=mycluster:scratch: Recovery is required. Waiting for a non-spectator to mount.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2018-07-06 03:40:46 +08:00
|
|
|
if (sdp->sd_args.ar_spectator) {
|
|
|
|
|
fs_info(sdp, "Recovery is required. Waiting for a "
|
|
|
|
|
"non-spectator to mount.\n");
|
|
|
|
|
msleep_interruptible(1000);
|
|
|
|
|
} else {
|
|
|
|
|
fs_info(sdp, "control_mount wait1 block %u start %u "
|
|
|
|
|
"mount %u lvb %u flags %lx\n", block_gen,
|
|
|
|
|
start_gen, mount_gen, lvb_gen,
|
|
|
|
|
ls->ls_recover_flags);
|
|
|
|
|
}
|
2012-01-10 06:18:05 +08:00
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
goto restart;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (lvb_gen != start_gen) {
|
|
|
|
|
/* wait for mounted nodes to update control_lock lvb to the
|
|
|
|
|
latest recovery generation */
|
|
|
|
|
fs_info(sdp, "control_mount wait2 block %u start %u mount %u "
|
|
|
|
|
"lvb %u flags %lx\n", block_gen, start_gen, mount_gen,
|
|
|
|
|
lvb_gen, ls->ls_recover_flags);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
goto restart;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (block_gen == start_gen) {
|
|
|
|
|
/* dlm recovery in progress, wait for it to finish */
|
|
|
|
|
fs_info(sdp, "control_mount wait3 block %u start %u mount %u "
|
|
|
|
|
"lvb %u flags %lx\n", block_gen, start_gen, mount_gen,
|
|
|
|
|
lvb_gen, ls->ls_recover_flags);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
goto restart;
|
2009-01-12 18:43:39 +08:00
|
|
|
}
|
|
|
|
|
|
2012-01-10 06:18:05 +08:00
|
|
|
clear_bit(DFL_BLOCK_LOCKS, &ls->ls_recover_flags);
|
|
|
|
|
set_bit(DFL_MOUNT_DONE, &ls->ls_recover_flags);
|
|
|
|
|
memset(ls->ls_recover_submit, 0, ls->ls_recover_size*sizeof(uint32_t));
|
|
|
|
|
memset(ls->ls_recover_result, 0, ls->ls_recover_size*sizeof(uint32_t));
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
fail:
|
|
|
|
|
mounted_unlock(sdp);
|
|
|
|
|
control_unlock(sdp);
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int control_first_done(struct gfs2_sbd *sdp)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
uint32_t start_gen, block_gen;
|
|
|
|
|
int error;
|
|
|
|
|
|
|
|
|
|
restart:
|
|
|
|
|
spin_lock(&ls->ls_recover_spin);
|
|
|
|
|
start_gen = ls->ls_recover_start;
|
|
|
|
|
block_gen = ls->ls_recover_block;
|
|
|
|
|
|
|
|
|
|
if (test_bit(DFL_BLOCK_LOCKS, &ls->ls_recover_flags) ||
|
|
|
|
|
!test_bit(DFL_MOUNT_DONE, &ls->ls_recover_flags) ||
|
|
|
|
|
!test_bit(DFL_FIRST_MOUNT, &ls->ls_recover_flags)) {
|
|
|
|
|
/* sanity check, should not happen */
|
|
|
|
|
fs_err(sdp, "control_first_done start %u block %u flags %lx\n",
|
|
|
|
|
start_gen, block_gen, ls->ls_recover_flags);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
control_unlock(sdp);
|
|
|
|
|
return -1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (start_gen == block_gen) {
|
|
|
|
|
/*
|
|
|
|
|
* Wait for the end of a dlm recovery cycle to switch from
|
|
|
|
|
* first mounter recovery. We can ignore any recover_slot
|
|
|
|
|
* callbacks between the recover_prep and next recover_done
|
|
|
|
|
* because we are still the first mounter and any failed nodes
|
|
|
|
|
* have not fully mounted, so they don't need recovery.
|
|
|
|
|
*/
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
fs_info(sdp, "control_first_done wait gen %u\n", start_gen);
|
|
|
|
|
|
|
|
|
|
wait_on_bit(&ls->ls_recover_flags, DFL_DLM_RECOVERY,
|
sched: Remove proliferation of wait_on_bit() action functions
The current "wait_on_bit" interface requires an 'action'
function to be provided which does the actual waiting.
There are over 20 such functions, many of them identical.
Most cases can be satisfied by one of just two functions, one
which uses io_schedule() and one which just uses schedule().
So:
Rename wait_on_bit and wait_on_bit_lock to
wait_on_bit_action and wait_on_bit_lock_action
to make it explicit that they need an action function.
Introduce new wait_on_bit{,_lock} and wait_on_bit{,_lock}_io
which are *not* given an action function but implicitly use
a standard one.
The decision to error-out if a signal is pending is now made
based on the 'mode' argument rather than being encoded in the action
function.
All instances of the old wait_on_bit and wait_on_bit_lock which
can use the new version have been changed accordingly and their
action functions have been discarded.
wait_on_bit{_lock} does not return any specific error code in the
event of a signal so the caller must check for non-zero and
interpolate their own error code as appropriate.
The wait_on_bit() call in __fscache_wait_on_invalidate() was
ambiguous as it specified TASK_UNINTERRUPTIBLE but used
fscache_wait_bit_interruptible as an action function.
David Howells confirms this should be uniformly
"uninterruptible"
The main remaining user of wait_on_bit{,_lock}_action is NFS
which needs to use a freezer-aware schedule() call.
A comment in fs/gfs2/glock.c notes that having multiple 'action'
functions is useful as they display differently in the 'wchan'
field of 'ps'. (and /proc/$PID/wchan).
As the new bit_wait{,_io} functions are tagged "__sched", they
will not show up at all, but something higher in the stack. So
the distinction will still be visible, only with different
function names (gds2_glock_wait versus gfs2_glock_dq_wait in the
gfs2/glock.c case).
Since first version of this patch (against 3.15) two new action
functions appeared, on in NFS and one in CIFS. CIFS also now
uses an action function that makes the same freezer aware
schedule call as NFS.
Signed-off-by: NeilBrown <neilb@suse.de>
Acked-by: David Howells <dhowells@redhat.com> (fscache, keys)
Acked-by: Steven Whitehouse <swhiteho@redhat.com> (gfs2)
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Steve French <sfrench@samba.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20140707051603.28027.72349.stgit@notabene.brown
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2014-07-07 13:16:04 +08:00
|
|
|
TASK_UNINTERRUPTIBLE);
|
2012-01-10 06:18:05 +08:00
|
|
|
goto restart;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
clear_bit(DFL_FIRST_MOUNT, &ls->ls_recover_flags);
|
|
|
|
|
set_bit(DFL_FIRST_MOUNT_DONE, &ls->ls_recover_flags);
|
|
|
|
|
memset(ls->ls_recover_submit, 0, ls->ls_recover_size*sizeof(uint32_t));
|
|
|
|
|
memset(ls->ls_recover_result, 0, ls->ls_recover_size*sizeof(uint32_t));
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
|
2013-03-06 05:01:47 +08:00
|
|
|
memset(ls->ls_lvb_bits, 0, GDLM_LVB_SIZE);
|
|
|
|
|
control_lvb_write(ls, start_gen, ls->ls_lvb_bits);
|
2012-01-10 06:18:05 +08:00
|
|
|
|
|
|
|
|
error = mounted_lock(sdp, DLM_LOCK_PR, DLM_LKF_CONVERT);
|
|
|
|
|
if (error)
|
|
|
|
|
fs_err(sdp, "control_first_done mounted PR error %d\n", error);
|
|
|
|
|
|
|
|
|
|
error = control_lock(sdp, DLM_LOCK_NL, DLM_LKF_CONVERT|DLM_LKF_VALBLK);
|
2009-01-12 18:43:39 +08:00
|
|
|
if (error)
|
2012-01-10 06:18:05 +08:00
|
|
|
fs_err(sdp, "control_first_done control NL error %d\n", error);
|
2009-01-12 18:43:39 +08:00
|
|
|
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-10 06:18:05 +08:00
|
|
|
/*
|
|
|
|
|
* Expand static jid arrays if necessary (by increments of RECOVER_SIZE_INC)
|
2022-06-23 17:37:16 +08:00
|
|
|
* to accommodate the largest slot number. (NB dlm slot numbers start at 1,
|
2012-01-10 06:18:05 +08:00
|
|
|
* gfs2 jids start at 0, so jid = slot - 1)
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#define RECOVER_SIZE_INC 16
|
|
|
|
|
|
|
|
|
|
static int set_recover_size(struct gfs2_sbd *sdp, struct dlm_slot *slots,
|
|
|
|
|
int num_slots)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
uint32_t *submit = NULL;
|
|
|
|
|
uint32_t *result = NULL;
|
|
|
|
|
uint32_t old_size, new_size;
|
|
|
|
|
int i, max_jid;
|
|
|
|
|
|
2013-03-06 05:01:47 +08:00
|
|
|
if (!ls->ls_lvb_bits) {
|
|
|
|
|
ls->ls_lvb_bits = kzalloc(GDLM_LVB_SIZE, GFP_NOFS);
|
|
|
|
|
if (!ls->ls_lvb_bits)
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
2012-01-10 06:18:05 +08:00
|
|
|
max_jid = 0;
|
|
|
|
|
for (i = 0; i < num_slots; i++) {
|
|
|
|
|
if (max_jid < slots[i].slot - 1)
|
|
|
|
|
max_jid = slots[i].slot - 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
old_size = ls->ls_recover_size;
|
2019-08-23 00:07:09 +08:00
|
|
|
new_size = old_size;
|
|
|
|
|
while (new_size < max_jid + 1)
|
|
|
|
|
new_size += RECOVER_SIZE_INC;
|
|
|
|
|
if (new_size == old_size)
|
2012-01-10 06:18:05 +08:00
|
|
|
return 0;
|
|
|
|
|
|
2014-06-26 02:40:45 +08:00
|
|
|
submit = kcalloc(new_size, sizeof(uint32_t), GFP_NOFS);
|
|
|
|
|
result = kcalloc(new_size, sizeof(uint32_t), GFP_NOFS);
|
2012-01-10 06:18:05 +08:00
|
|
|
if (!submit || !result) {
|
|
|
|
|
kfree(submit);
|
|
|
|
|
kfree(result);
|
|
|
|
|
return -ENOMEM;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
spin_lock(&ls->ls_recover_spin);
|
|
|
|
|
memcpy(submit, ls->ls_recover_submit, old_size * sizeof(uint32_t));
|
|
|
|
|
memcpy(result, ls->ls_recover_result, old_size * sizeof(uint32_t));
|
|
|
|
|
kfree(ls->ls_recover_submit);
|
|
|
|
|
kfree(ls->ls_recover_result);
|
|
|
|
|
ls->ls_recover_submit = submit;
|
|
|
|
|
ls->ls_recover_result = result;
|
|
|
|
|
ls->ls_recover_size = new_size;
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void free_recover_size(struct lm_lockstruct *ls)
|
|
|
|
|
{
|
2013-03-06 05:01:47 +08:00
|
|
|
kfree(ls->ls_lvb_bits);
|
2012-01-10 06:18:05 +08:00
|
|
|
kfree(ls->ls_recover_submit);
|
|
|
|
|
kfree(ls->ls_recover_result);
|
|
|
|
|
ls->ls_recover_submit = NULL;
|
|
|
|
|
ls->ls_recover_result = NULL;
|
|
|
|
|
ls->ls_recover_size = 0;
|
2017-08-16 00:54:09 +08:00
|
|
|
ls->ls_lvb_bits = NULL;
|
2012-01-10 06:18:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* dlm calls before it does lock recovery */
|
|
|
|
|
|
|
|
|
|
static void gdlm_recover_prep(void *arg)
|
|
|
|
|
{
|
|
|
|
|
struct gfs2_sbd *sdp = arg;
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
|
gfs2: Ignore dlm recovery requests if gfs2 is withdrawn
When a node fails, user space informs dlm of the node failure,
and dlm instructs gfs2 on the surviving nodes to perform journal
recovery. It does this by calling various callback functions in
lock_dlm.c. To mark its progress, it keeps generation numbers
and recover bits in a dlm "control" lock lvb, which is seen by
all nodes to determine which journals need to be replayed.
The gfs2 on all nodes get the same recovery requests from dlm,
so they all try to do the recovery, but only one will be
granted the exclusive lock on the journal. The others fail
with a "Busy" message on their "try lock."
However, when a node is withdrawn, it cannot safely do any
recovery or replay any journals. To make matters worse,
gfs2 might withdraw as a result of attempting recovery. For
example, this might happen if the device goes offline, or if
an hba fails. But in today's gfs2 code, it doesn't check for
being withdrawn at any step in the recovery process. What's
worse is that these callbacks from dlm have no return code,
so there is no way to indicate failure back to dlm. We can
send a "Recovery failed" uevent eventually, but that tells
user space what happened, not dlm's kernel code.
Before this patch, lock_dlm would perform its recovery steps but
ignore the result, and eventually it would still update its
generation number in the lvb, despite the fact that it may have
withdrawn or encountered an error. The other nodes would then
see the newer generation number in the lvb and conclude that
they don't need to do recovery because the generation number
is newer than the last one they saw. They think a different
node has already recovered the journal.
This patch adds checks to several of the callbacks used by dlm
in its recovery state machine so that the functions are ignored
and skipped if an io error has occurred or if the file system
is withdrawn. That prevents the lvb bits from being updated, and
therefore dlm and user space still see the need for recovery to
take place.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
2019-02-13 04:58:40 +08:00
|
|
|
if (gfs2_withdrawn(sdp)) {
|
|
|
|
|
fs_err(sdp, "recover_prep ignored due to withdraw.\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
2012-01-10 06:18:05 +08:00
|
|
|
spin_lock(&ls->ls_recover_spin);
|
|
|
|
|
ls->ls_recover_block = ls->ls_recover_start;
|
|
|
|
|
set_bit(DFL_DLM_RECOVERY, &ls->ls_recover_flags);
|
|
|
|
|
|
|
|
|
|
if (!test_bit(DFL_MOUNT_DONE, &ls->ls_recover_flags) ||
|
|
|
|
|
test_bit(DFL_FIRST_MOUNT, &ls->ls_recover_flags)) {
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
set_bit(DFL_BLOCK_LOCKS, &ls->ls_recover_flags);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* dlm calls after recover_prep has been completed on all lockspace members;
|
|
|
|
|
identifies slot/jid of failed member */
|
|
|
|
|
|
|
|
|
|
static void gdlm_recover_slot(void *arg, struct dlm_slot *slot)
|
|
|
|
|
{
|
|
|
|
|
struct gfs2_sbd *sdp = arg;
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
int jid = slot->slot - 1;
|
|
|
|
|
|
gfs2: Ignore dlm recovery requests if gfs2 is withdrawn
When a node fails, user space informs dlm of the node failure,
and dlm instructs gfs2 on the surviving nodes to perform journal
recovery. It does this by calling various callback functions in
lock_dlm.c. To mark its progress, it keeps generation numbers
and recover bits in a dlm "control" lock lvb, which is seen by
all nodes to determine which journals need to be replayed.
The gfs2 on all nodes get the same recovery requests from dlm,
so they all try to do the recovery, but only one will be
granted the exclusive lock on the journal. The others fail
with a "Busy" message on their "try lock."
However, when a node is withdrawn, it cannot safely do any
recovery or replay any journals. To make matters worse,
gfs2 might withdraw as a result of attempting recovery. For
example, this might happen if the device goes offline, or if
an hba fails. But in today's gfs2 code, it doesn't check for
being withdrawn at any step in the recovery process. What's
worse is that these callbacks from dlm have no return code,
so there is no way to indicate failure back to dlm. We can
send a "Recovery failed" uevent eventually, but that tells
user space what happened, not dlm's kernel code.
Before this patch, lock_dlm would perform its recovery steps but
ignore the result, and eventually it would still update its
generation number in the lvb, despite the fact that it may have
withdrawn or encountered an error. The other nodes would then
see the newer generation number in the lvb and conclude that
they don't need to do recovery because the generation number
is newer than the last one they saw. They think a different
node has already recovered the journal.
This patch adds checks to several of the callbacks used by dlm
in its recovery state machine so that the functions are ignored
and skipped if an io error has occurred or if the file system
is withdrawn. That prevents the lvb bits from being updated, and
therefore dlm and user space still see the need for recovery to
take place.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
2019-02-13 04:58:40 +08:00
|
|
|
if (gfs2_withdrawn(sdp)) {
|
|
|
|
|
fs_err(sdp, "recover_slot jid %d ignored due to withdraw.\n",
|
|
|
|
|
jid);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2012-01-10 06:18:05 +08:00
|
|
|
spin_lock(&ls->ls_recover_spin);
|
|
|
|
|
if (ls->ls_recover_size < jid + 1) {
|
2018-01-31 01:32:30 +08:00
|
|
|
fs_err(sdp, "recover_slot jid %d gen %u short size %d\n",
|
2012-01-10 06:18:05 +08:00
|
|
|
jid, ls->ls_recover_block, ls->ls_recover_size);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ls->ls_recover_submit[jid]) {
|
2014-02-15 02:10:19 +08:00
|
|
|
fs_info(sdp, "recover_slot jid %d gen %u prev %u\n",
|
2012-01-10 06:18:05 +08:00
|
|
|
jid, ls->ls_recover_block, ls->ls_recover_submit[jid]);
|
|
|
|
|
}
|
|
|
|
|
ls->ls_recover_submit[jid] = ls->ls_recover_block;
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* dlm calls after recover_slot and after it completes lock recovery */
|
|
|
|
|
|
|
|
|
|
static void gdlm_recover_done(void *arg, struct dlm_slot *slots, int num_slots,
|
|
|
|
|
int our_slot, uint32_t generation)
|
|
|
|
|
{
|
|
|
|
|
struct gfs2_sbd *sdp = arg;
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
|
gfs2: Ignore dlm recovery requests if gfs2 is withdrawn
When a node fails, user space informs dlm of the node failure,
and dlm instructs gfs2 on the surviving nodes to perform journal
recovery. It does this by calling various callback functions in
lock_dlm.c. To mark its progress, it keeps generation numbers
and recover bits in a dlm "control" lock lvb, which is seen by
all nodes to determine which journals need to be replayed.
The gfs2 on all nodes get the same recovery requests from dlm,
so they all try to do the recovery, but only one will be
granted the exclusive lock on the journal. The others fail
with a "Busy" message on their "try lock."
However, when a node is withdrawn, it cannot safely do any
recovery or replay any journals. To make matters worse,
gfs2 might withdraw as a result of attempting recovery. For
example, this might happen if the device goes offline, or if
an hba fails. But in today's gfs2 code, it doesn't check for
being withdrawn at any step in the recovery process. What's
worse is that these callbacks from dlm have no return code,
so there is no way to indicate failure back to dlm. We can
send a "Recovery failed" uevent eventually, but that tells
user space what happened, not dlm's kernel code.
Before this patch, lock_dlm would perform its recovery steps but
ignore the result, and eventually it would still update its
generation number in the lvb, despite the fact that it may have
withdrawn or encountered an error. The other nodes would then
see the newer generation number in the lvb and conclude that
they don't need to do recovery because the generation number
is newer than the last one they saw. They think a different
node has already recovered the journal.
This patch adds checks to several of the callbacks used by dlm
in its recovery state machine so that the functions are ignored
and skipped if an io error has occurred or if the file system
is withdrawn. That prevents the lvb bits from being updated, and
therefore dlm and user space still see the need for recovery to
take place.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
2019-02-13 04:58:40 +08:00
|
|
|
if (gfs2_withdrawn(sdp)) {
|
|
|
|
|
fs_err(sdp, "recover_done ignored due to withdraw.\n");
|
|
|
|
|
return;
|
|
|
|
|
}
|
2012-01-10 06:18:05 +08:00
|
|
|
/* ensure the ls jid arrays are large enough */
|
|
|
|
|
set_recover_size(sdp, slots, num_slots);
|
|
|
|
|
|
|
|
|
|
spin_lock(&ls->ls_recover_spin);
|
|
|
|
|
ls->ls_recover_start = generation;
|
|
|
|
|
|
|
|
|
|
if (!ls->ls_recover_mount) {
|
|
|
|
|
ls->ls_recover_mount = generation;
|
|
|
|
|
ls->ls_jid = our_slot - 1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!test_bit(DFL_UNMOUNT, &ls->ls_recover_flags))
|
|
|
|
|
queue_delayed_work(gfs2_control_wq, &sdp->sd_control_work, 0);
|
|
|
|
|
|
|
|
|
|
clear_bit(DFL_DLM_RECOVERY, &ls->ls_recover_flags);
|
2014-03-18 01:06:10 +08:00
|
|
|
smp_mb__after_atomic();
|
2012-01-10 06:18:05 +08:00
|
|
|
wake_up_bit(&ls->ls_recover_flags, DFL_DLM_RECOVERY);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/* gfs2_recover thread has a journal recovery result */
|
|
|
|
|
|
|
|
|
|
static void gdlm_recovery_result(struct gfs2_sbd *sdp, unsigned int jid,
|
|
|
|
|
unsigned int result)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
|
gfs2: Ignore dlm recovery requests if gfs2 is withdrawn
When a node fails, user space informs dlm of the node failure,
and dlm instructs gfs2 on the surviving nodes to perform journal
recovery. It does this by calling various callback functions in
lock_dlm.c. To mark its progress, it keeps generation numbers
and recover bits in a dlm "control" lock lvb, which is seen by
all nodes to determine which journals need to be replayed.
The gfs2 on all nodes get the same recovery requests from dlm,
so they all try to do the recovery, but only one will be
granted the exclusive lock on the journal. The others fail
with a "Busy" message on their "try lock."
However, when a node is withdrawn, it cannot safely do any
recovery or replay any journals. To make matters worse,
gfs2 might withdraw as a result of attempting recovery. For
example, this might happen if the device goes offline, or if
an hba fails. But in today's gfs2 code, it doesn't check for
being withdrawn at any step in the recovery process. What's
worse is that these callbacks from dlm have no return code,
so there is no way to indicate failure back to dlm. We can
send a "Recovery failed" uevent eventually, but that tells
user space what happened, not dlm's kernel code.
Before this patch, lock_dlm would perform its recovery steps but
ignore the result, and eventually it would still update its
generation number in the lvb, despite the fact that it may have
withdrawn or encountered an error. The other nodes would then
see the newer generation number in the lvb and conclude that
they don't need to do recovery because the generation number
is newer than the last one they saw. They think a different
node has already recovered the journal.
This patch adds checks to several of the callbacks used by dlm
in its recovery state machine so that the functions are ignored
and skipped if an io error has occurred or if the file system
is withdrawn. That prevents the lvb bits from being updated, and
therefore dlm and user space still see the need for recovery to
take place.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Reviewed-by: Andreas Gruenbacher <agruenba@redhat.com>
2019-02-13 04:58:40 +08:00
|
|
|
if (gfs2_withdrawn(sdp)) {
|
|
|
|
|
fs_err(sdp, "recovery_result jid %d ignored due to withdraw.\n",
|
|
|
|
|
jid);
|
|
|
|
|
return;
|
|
|
|
|
}
|
2012-01-10 06:18:05 +08:00
|
|
|
if (test_bit(DFL_NO_DLM_OPS, &ls->ls_recover_flags))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
/* don't care about the recovery of own journal during mount */
|
|
|
|
|
if (jid == ls->ls_jid)
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
spin_lock(&ls->ls_recover_spin);
|
|
|
|
|
if (test_bit(DFL_FIRST_MOUNT, &ls->ls_recover_flags)) {
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
if (ls->ls_recover_size < jid + 1) {
|
2018-01-31 01:32:30 +08:00
|
|
|
fs_err(sdp, "recovery_result jid %d short size %d\n",
|
2012-01-10 06:18:05 +08:00
|
|
|
jid, ls->ls_recover_size);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
fs_info(sdp, "recover jid %d result %s\n", jid,
|
|
|
|
|
result == LM_RD_GAVEUP ? "busy" : "success");
|
|
|
|
|
|
|
|
|
|
ls->ls_recover_result[jid] = result;
|
|
|
|
|
|
|
|
|
|
/* GAVEUP means another node is recovering the journal; delay our
|
|
|
|
|
next attempt to recover it, to give the other node a chance to
|
|
|
|
|
finish before trying again */
|
|
|
|
|
|
|
|
|
|
if (!test_bit(DFL_UNMOUNT, &ls->ls_recover_flags))
|
|
|
|
|
queue_delayed_work(gfs2_control_wq, &sdp->sd_control_work,
|
|
|
|
|
result == LM_RD_GAVEUP ? HZ : 0);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-18 22:15:13 +08:00
|
|
|
static const struct dlm_lockspace_ops gdlm_lockspace_ops = {
|
2012-01-10 06:18:05 +08:00
|
|
|
.recover_prep = gdlm_recover_prep,
|
|
|
|
|
.recover_slot = gdlm_recover_slot,
|
|
|
|
|
.recover_done = gdlm_recover_done,
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static int gdlm_mount(struct gfs2_sbd *sdp, const char *table)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
char cluster[GFS2_LOCKNAME_LEN];
|
|
|
|
|
const char *fsname;
|
|
|
|
|
uint32_t flags;
|
|
|
|
|
int error, ops_result;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* initialize everything
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
INIT_DELAYED_WORK(&sdp->sd_control_work, gfs2_control_func);
|
|
|
|
|
spin_lock_init(&ls->ls_recover_spin);
|
|
|
|
|
ls->ls_recover_flags = 0;
|
|
|
|
|
ls->ls_recover_mount = 0;
|
|
|
|
|
ls->ls_recover_start = 0;
|
|
|
|
|
ls->ls_recover_block = 0;
|
|
|
|
|
ls->ls_recover_size = 0;
|
|
|
|
|
ls->ls_recover_submit = NULL;
|
|
|
|
|
ls->ls_recover_result = NULL;
|
2013-03-06 05:01:47 +08:00
|
|
|
ls->ls_lvb_bits = NULL;
|
2012-01-10 06:18:05 +08:00
|
|
|
|
|
|
|
|
error = set_recover_size(sdp, NULL, 0);
|
|
|
|
|
if (error)
|
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* prepare dlm_new_lockspace args
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
fsname = strchr(table, ':');
|
|
|
|
|
if (!fsname) {
|
|
|
|
|
fs_info(sdp, "no fsname found\n");
|
|
|
|
|
error = -EINVAL;
|
|
|
|
|
goto fail_free;
|
|
|
|
|
}
|
|
|
|
|
memset(cluster, 0, sizeof(cluster));
|
|
|
|
|
memcpy(cluster, table, strlen(table) - strlen(fsname));
|
|
|
|
|
fsname++;
|
|
|
|
|
|
|
|
|
|
flags = DLM_LSFL_FS | DLM_LSFL_NEWEXCL;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* create/join lockspace
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
error = dlm_new_lockspace(fsname, cluster, flags, GDLM_LVB_SIZE,
|
|
|
|
|
&gdlm_lockspace_ops, sdp, &ops_result,
|
|
|
|
|
&ls->ls_dlm);
|
|
|
|
|
if (error) {
|
|
|
|
|
fs_err(sdp, "dlm_new_lockspace error %d\n", error);
|
|
|
|
|
goto fail_free;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (ops_result < 0) {
|
|
|
|
|
/*
|
|
|
|
|
* dlm does not support ops callbacks,
|
|
|
|
|
* old dlm_controld/gfs_controld are used, try without ops.
|
|
|
|
|
*/
|
|
|
|
|
fs_info(sdp, "dlm lockspace ops not used\n");
|
|
|
|
|
free_recover_size(ls);
|
|
|
|
|
set_bit(DFL_NO_DLM_OPS, &ls->ls_recover_flags);
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (!test_bit(SDF_NOJOURNALID, &sdp->sd_flags)) {
|
|
|
|
|
fs_err(sdp, "dlm lockspace ops disallow jid preset\n");
|
|
|
|
|
error = -EINVAL;
|
|
|
|
|
goto fail_release;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* control_mount() uses control_lock to determine first mounter,
|
|
|
|
|
* and for later mounts, waits for any recoveries to be cleared.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
error = control_mount(sdp);
|
|
|
|
|
if (error) {
|
|
|
|
|
fs_err(sdp, "mount control error %d\n", error);
|
|
|
|
|
goto fail_release;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
ls->ls_first = !!test_bit(DFL_FIRST_MOUNT, &ls->ls_recover_flags);
|
|
|
|
|
clear_bit(SDF_NOJOURNALID, &sdp->sd_flags);
|
2014-03-18 01:06:10 +08:00
|
|
|
smp_mb__after_atomic();
|
2012-01-10 06:18:05 +08:00
|
|
|
wake_up_bit(&sdp->sd_flags, SDF_NOJOURNALID);
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
|
|
fail_release:
|
|
|
|
|
dlm_release_lockspace(ls->ls_dlm, 2);
|
|
|
|
|
fail_free:
|
|
|
|
|
free_recover_size(ls);
|
|
|
|
|
fail:
|
|
|
|
|
return error;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void gdlm_first_done(struct gfs2_sbd *sdp)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
int error;
|
|
|
|
|
|
|
|
|
|
if (test_bit(DFL_NO_DLM_OPS, &ls->ls_recover_flags))
|
|
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
error = control_first_done(sdp);
|
|
|
|
|
if (error)
|
|
|
|
|
fs_err(sdp, "mount first_done error %d\n", error);
|
|
|
|
|
}
|
|
|
|
|
|
2009-01-12 18:43:39 +08:00
|
|
|
static void gdlm_unmount(struct gfs2_sbd *sdp)
|
|
|
|
|
{
|
|
|
|
|
struct lm_lockstruct *ls = &sdp->sd_lockstruct;
|
|
|
|
|
|
2012-01-10 06:18:05 +08:00
|
|
|
if (test_bit(DFL_NO_DLM_OPS, &ls->ls_recover_flags))
|
|
|
|
|
goto release;
|
|
|
|
|
|
|
|
|
|
/* wait for gfs2_control_wq to be done with this mount */
|
|
|
|
|
|
|
|
|
|
spin_lock(&ls->ls_recover_spin);
|
|
|
|
|
set_bit(DFL_UNMOUNT, &ls->ls_recover_flags);
|
|
|
|
|
spin_unlock(&ls->ls_recover_spin);
|
2012-08-21 05:51:24 +08:00
|
|
|
flush_delayed_work(&sdp->sd_control_work);
|
2012-01-10 06:18:05 +08:00
|
|
|
|
|
|
|
|
/* mounted_lock and control_lock will be purged in dlm recovery */
|
|
|
|
|
release:
|
2009-01-12 18:43:39 +08:00
|
|
|
if (ls->ls_dlm) {
|
|
|
|
|
dlm_release_lockspace(ls->ls_dlm, 2);
|
|
|
|
|
ls->ls_dlm = NULL;
|
|
|
|
|
}
|
2012-01-10 06:18:05 +08:00
|
|
|
|
|
|
|
|
free_recover_size(ls);
|
2009-01-12 18:43:39 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const match_table_t dlm_tokens = {
|
|
|
|
|
{ Opt_jid, "jid=%d"},
|
|
|
|
|
{ Opt_id, "id=%d"},
|
|
|
|
|
{ Opt_first, "first=%d"},
|
|
|
|
|
{ Opt_nodir, "nodir=%d"},
|
|
|
|
|
{ Opt_err, NULL },
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
const struct lm_lockops gfs2_dlm_ops = {
|
|
|
|
|
.lm_proto_name = "lock_dlm",
|
|
|
|
|
.lm_mount = gdlm_mount,
|
2012-01-10 06:18:05 +08:00
|
|
|
.lm_first_done = gdlm_first_done,
|
|
|
|
|
.lm_recovery_result = gdlm_recovery_result,
|
2009-01-12 18:43:39 +08:00
|
|
|
.lm_unmount = gdlm_unmount,
|
|
|
|
|
.lm_put_lock = gdlm_put_lock,
|
|
|
|
|
.lm_lock = gdlm_lock,
|
|
|
|
|
.lm_cancel = gdlm_cancel,
|
|
|
|
|
.lm_tokens = &dlm_tokens,
|
|
|
|
|
};
|
|
|
|
|
|