2019-05-31 08:09:56 +00:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0-only */
|
2006-01-16 16:50:04 +00:00
|
|
|
/*
|
|
|
|
* Copyright (C) Sistina Software, Inc. 1997-2003 All rights reserved.
|
2008-01-29 04:31:39 +00:00
|
|
|
* Copyright (C) 2004-2008 Red Hat, Inc. All rights reserved.
|
2006-01-16 16:50:04 +00:00
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef __INCORE_DOT_H__
|
|
|
|
#define __INCORE_DOT_H__
|
|
|
|
|
2006-09-05 14:39:21 +00:00
|
|
|
#include <linux/fs.h>
|
2011-01-10 06:18:25 +00:00
|
|
|
#include <linux/kobject.h>
|
[GFS2] delay glock demote for a minimum hold time
When a lot of IO, with some distributed mmap IO, is run on a GFS2 filesystem in
a cluster, it will deadlock. The reason is that do_no_page() will repeatedly
call gfs2_sharewrite_nopage(), because each node keeps giving up the glock
too early, and is forced to call unmap_mapping_range(). This bumps the
mapping->truncate_count sequence count, forcing do_no_page() to retry. This
patch institutes a minimum glock hold time a tenth a second. This insures
that even in heavy contention cases, the node has enough time to get some
useful work done before it gives up the glock.
A second issue is that when gfs2_glock_dq() is called from within a page fault
to demote a lock, and the associated page needs to be written out, it will
try to acqire a lock on it, but it has already been locked at a higher level.
This patch puts makes gfs2_glock_dq() use the work queue as well, to avoid this
issue. This is the same patch as Steve Whitehouse originally proposed to fix
this issue, execpt that gfs2_glock_dq() now grabs a reference to the glock
before it queues up the work on it.
Signed-off-by: Benjamin E. Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2007-08-23 18:19:05 +00:00
|
|
|
#include <linux/workqueue.h>
|
2009-01-12 10:43:39 +00:00
|
|
|
#include <linux/dlm.h>
|
|
|
|
#include <linux/buffer_head.h>
|
2011-01-19 09:30:01 +00:00
|
|
|
#include <linux/rcupdate.h>
|
|
|
|
#include <linux/rculist_bl.h>
|
2011-07-11 07:53:30 +00:00
|
|
|
#include <linux/completion.h>
|
GFS2: Use rbtree for resource groups and clean up bitmap buffer ref count scheme
Here is an update of Bob's original rbtree patch which, in addition, also
resolves the rather strange ref counting that was being done relating to
the bitmap blocks.
Originally we had a dual system for journaling resource groups. The metadata
blocks were journaled and also the rgrp itself was added to a list. The reason
for adding the rgrp to the list in the journal was so that the "repolish
clones" code could be run to update the free space, and potentially send any
discard requests when the log was flushed. This was done by comparing the
"cloned" bitmap with what had been written back on disk during the transaction
commit.
Due to this, there was a requirement to hang on to the rgrps' bitmap buffers
until the journal had been flushed. For that reason, there was a rather
complicated set up in the ->go_lock ->go_unlock functions for rgrps involving
both a mutex and a spinlock (the ->sd_rindex_spin) to maintain a reference
count on the buffers.
However, the journal maintains a reference count on the buffers anyway, since
they are being journaled as metadata buffers. So by moving the code which deals
with the post-journal accounting for bitmap blocks to the metadata journaling
code, we can entirely dispense with the rather strange buffer ref counting
scheme and also the requirement to journal the rgrps.
The net result of all this is that the ->sd_rindex_spin is left to do exactly
one job, and that is to look after the rbtree or rgrps.
This patch is designed to be a stepping stone towards using RCU for the rbtree
of resource groups, however the reduction in the number of uses of the
->sd_rindex_spin is likely to have benefits for multi-threaded workloads,
anyway.
The patch retains ->go_lock and ->go_unlock for rgrps, however these maybe also
be removed in future in favour of calling the functions directly where required
in the code. That will allow locking of resource groups without needing to
actually read them in - something that could be useful in speeding up statfs.
In the mean time though it is valid to dereference ->bi_bh only when the rgrp
is locked. This is basically the same rule as before, modulo the references not
being valid until the following journal flush.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Cc: Benjamin Marzinski <bmarzins@redhat.com>
2011-08-31 08:53:19 +00:00
|
|
|
#include <linux/rbtree.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 10:38:36 +00:00
|
|
|
#include <linux/ktime.h>
|
|
|
|
#include <linux/percpu.h>
|
2013-10-15 14:18:08 +00:00
|
|
|
#include <linux/lockref.h>
|
2015-03-16 16:02:46 +00:00
|
|
|
#include <linux/rhashtable.h>
|
2021-02-08 19:44:26 +00:00
|
|
|
#include <linux/mutex.h>
|
2006-09-05 14:39:21 +00:00
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
#define DIO_WAIT 0x00000010
|
|
|
|
#define DIO_METADATA 0x00000020
|
|
|
|
|
|
|
|
struct gfs2_log_operations;
|
2012-05-01 16:00:34 +00:00
|
|
|
struct gfs2_bufdata;
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_holder;
|
|
|
|
struct gfs2_glock;
|
|
|
|
struct gfs2_quota_data;
|
|
|
|
struct gfs2_trans;
|
|
|
|
struct gfs2_jdesc;
|
|
|
|
struct gfs2_sbd;
|
2009-01-12 10:43:39 +00:00
|
|
|
struct lm_lockops;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
typedef void (*gfs2_glop_bh_t) (struct gfs2_glock *gl, unsigned int ret);
|
|
|
|
|
2007-06-01 13:11:58 +00:00
|
|
|
struct gfs2_log_header_host {
|
|
|
|
u64 lh_sequence; /* Sequence number of this transaction */
|
|
|
|
u32 lh_flags; /* GFS2_LOG_HEAD_... */
|
|
|
|
u32 lh_tail; /* Block number of log tail */
|
|
|
|
u32 lh_blkno;
|
2020-10-20 20:58:03 +00:00
|
|
|
|
|
|
|
s64 lh_local_total;
|
|
|
|
s64 lh_local_free;
|
|
|
|
s64 lh_local_dinodes;
|
2007-06-01 13:11:58 +00:00
|
|
|
};
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
/*
|
|
|
|
* Structure of operations that are associated with each
|
|
|
|
* type of element in the log.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct gfs2_log_operations {
|
2014-02-21 15:22:35 +00:00
|
|
|
void (*lo_before_commit) (struct gfs2_sbd *sdp, struct gfs2_trans *tr);
|
GFS2: replace gfs2_ail structure with gfs2_trans
In order to allow transactions and log flushes to happen at the same
time, gfs2 needs to move the transaction accounting and active items
list code into the gfs2_trans structure. As a first step toward this,
this patch removes the gfs2_ail structure, and handles the active items
list in the gfs_trans structure. This keeps gfs2 from allocating an ail
structure on log flushes, and gives us a struture that can later be used
to store the transaction accounting outside of the gfs2 superblock
structure.
With this patch, at the end of a transaction, gfs2 will add the
gfs2_trans structure to the superblock if there is not one already.
This structure now has the active items fields that were previously in
gfs2_ail. This is not necessary in the case where the transaction was
simply used to add revokes, since these are never written outside of the
journal, and thus, don't need an active items list.
Also, in order to make sure that the transaction structure is not
removed while it's still in use by gfs2_trans_end, unlocking the
sd_log_flush_lock has to happen slightly later in ending the
transaction.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2013-04-06 01:31:46 +00:00
|
|
|
void (*lo_after_commit) (struct gfs2_sbd *sdp, struct gfs2_trans *tr);
|
2006-01-16 16:50:04 +00:00
|
|
|
void (*lo_before_scan) (struct gfs2_jdesc *jd,
|
2006-10-14 01:47:13 +00:00
|
|
|
struct gfs2_log_header_host *head, int pass);
|
2006-01-16 16:50:04 +00:00
|
|
|
int (*lo_scan_elements) (struct gfs2_jdesc *jd, unsigned int start,
|
|
|
|
struct gfs2_log_descriptor *ld, __be64 *ptr,
|
|
|
|
int pass);
|
|
|
|
void (*lo_after_scan) (struct gfs2_jdesc *jd, int error, int pass);
|
2006-04-07 15:17:32 +00:00
|
|
|
const char *lo_name;
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
2009-05-21 11:23:12 +00:00
|
|
|
#define GBF_FULL 1
|
|
|
|
|
2018-08-07 15:07:00 +00:00
|
|
|
/**
|
|
|
|
* Clone bitmaps (bi_clone):
|
|
|
|
*
|
|
|
|
* - When a block is freed, we remember the previous state of the block in the
|
|
|
|
* clone bitmap, and only mark the block as free in the real bitmap.
|
|
|
|
*
|
|
|
|
* - When looking for a block to allocate, we check for a free block in the
|
|
|
|
* clone bitmap, and if no clone bitmap exists, in the real bitmap.
|
|
|
|
*
|
|
|
|
* - For allocating a block, we mark it as allocated in the real bitmap, and if
|
|
|
|
* a clone bitmap exists, also in the clone bitmap.
|
|
|
|
*
|
|
|
|
* - At the end of a log_flush, we copy the real bitmap into the clone bitmap
|
|
|
|
* to make the clone bitmap reflect the current allocation state.
|
|
|
|
* (Alternatively, we could remove the clone bitmap.)
|
|
|
|
*
|
|
|
|
* The clone bitmaps are in-core only, and is never written to disk.
|
|
|
|
*
|
|
|
|
* These steps ensure that blocks which have been freed in a transaction cannot
|
|
|
|
* be reallocated in that same transaction.
|
|
|
|
*/
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_bitmap {
|
|
|
|
struct buffer_head *bi_bh;
|
|
|
|
char *bi_clone;
|
2009-05-21 11:23:12 +00:00
|
|
|
unsigned long bi_flags;
|
2006-09-04 16:49:07 +00:00
|
|
|
u32 bi_offset;
|
|
|
|
u32 bi_start;
|
2018-09-26 22:32:46 +00:00
|
|
|
u32 bi_bytes;
|
2013-09-11 18:44:02 +00:00
|
|
|
u32 bi_blocks;
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct gfs2_rgrpd {
|
GFS2: Use rbtree for resource groups and clean up bitmap buffer ref count scheme
Here is an update of Bob's original rbtree patch which, in addition, also
resolves the rather strange ref counting that was being done relating to
the bitmap blocks.
Originally we had a dual system for journaling resource groups. The metadata
blocks were journaled and also the rgrp itself was added to a list. The reason
for adding the rgrp to the list in the journal was so that the "repolish
clones" code could be run to update the free space, and potentially send any
discard requests when the log was flushed. This was done by comparing the
"cloned" bitmap with what had been written back on disk during the transaction
commit.
Due to this, there was a requirement to hang on to the rgrps' bitmap buffers
until the journal had been flushed. For that reason, there was a rather
complicated set up in the ->go_lock ->go_unlock functions for rgrps involving
both a mutex and a spinlock (the ->sd_rindex_spin) to maintain a reference
count on the buffers.
However, the journal maintains a reference count on the buffers anyway, since
they are being journaled as metadata buffers. So by moving the code which deals
with the post-journal accounting for bitmap blocks to the metadata journaling
code, we can entirely dispense with the rather strange buffer ref counting
scheme and also the requirement to journal the rgrps.
The net result of all this is that the ->sd_rindex_spin is left to do exactly
one job, and that is to look after the rbtree or rgrps.
This patch is designed to be a stepping stone towards using RCU for the rbtree
of resource groups, however the reduction in the number of uses of the
->sd_rindex_spin is likely to have benefits for multi-threaded workloads,
anyway.
The patch retains ->go_lock and ->go_unlock for rgrps, however these maybe also
be removed in future in favour of calling the functions directly where required
in the code. That will allow locking of resource groups without needing to
actually read them in - something that could be useful in speeding up statfs.
In the mean time though it is valid to dereference ->bi_bh only when the rgrp
is locked. This is basically the same rule as before, modulo the references not
being valid until the following journal flush.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Cc: Benjamin Marzinski <bmarzins@redhat.com>
2011-08-31 08:53:19 +00:00
|
|
|
struct rb_node rd_node; /* Link with superblock */
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_glock *rd_gl; /* Glock for this rgrp */
|
2007-06-01 13:11:58 +00:00
|
|
|
u64 rd_addr; /* grp block disk address */
|
|
|
|
u64 rd_data0; /* first data location */
|
|
|
|
u32 rd_length; /* length of rgrp header in fs blocks */
|
|
|
|
u32 rd_data; /* num of data blocks in rgrp */
|
|
|
|
u32 rd_bitbytes; /* number of bytes in data bitmaps */
|
2008-11-04 10:25:13 +00:00
|
|
|
u32 rd_free;
|
2020-10-22 18:34:29 +00:00
|
|
|
u32 rd_requested; /* number of blocks in rd_rstree */
|
2018-10-02 13:59:54 +00:00
|
|
|
u32 rd_reserved; /* number of reserved blocks */
|
2008-11-04 10:32:57 +00:00
|
|
|
u32 rd_free_clone;
|
|
|
|
u32 rd_dinodes;
|
2008-11-04 10:19:03 +00:00
|
|
|
u64 rd_igeneration;
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_bitmap *rd_bits;
|
|
|
|
struct gfs2_sbd *rd_sbd;
|
GFS2: Use lvbs for storing rgrp information with mount option
Instead of reading in the resource groups when gfs2 is checking
for free space to allocate from, gfs2 can store the necessary infromation
in the resource group's lvb. Also, instead of searching for unlinked
inodes in every resource group that's checked for free space, gfs2 can
store the number of unlinked but inodes in the lvb, and only check for
unlinked inodes if it will find some.
The first time a resource group is locked, the lvb must initialized.
Since this involves counting the unlinked inodes in the resource group,
this takes a little extra time. But after that, if the resource group
is locked with GL_SKIP, the buffer head won't be read in unless it's
actually needed.
Enabling the resource groups lvbs is done via the rgrplvb mount option. If
this option isn't set, the lvbs will still be set and updated, but they won't
be verfied or used by the filesystem. To safely turn on this option, all of
the nodes mounting the filesystem must be running code with this patch, and
the filesystem must have been completely unmounted since they were updated.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-05-30 04:01:09 +00:00
|
|
|
struct gfs2_rgrp_lvb *rd_rgl;
|
2008-11-04 10:32:57 +00:00
|
|
|
u32 rd_last_alloc;
|
2009-05-21 14:18:19 +00:00
|
|
|
u32 rd_flags;
|
2013-11-25 11:16:25 +00:00
|
|
|
u32 rd_extfail_pt; /* extent failure point */
|
2009-05-20 09:48:47 +00:00
|
|
|
#define GFS2_RDF_CHECK 0x10000000 /* check for unlinked inodes */
|
|
|
|
#define GFS2_RDF_ERROR 0x40000000 /* error in rg */
|
2014-10-29 13:02:28 +00:00
|
|
|
#define GFS2_RDF_PREFERRED 0x80000000 /* This rgrp is preferred */
|
2009-05-20 09:48:47 +00:00
|
|
|
#define GFS2_RDF_MASK 0xf0000000 /* mask for internal flags */
|
2012-07-19 12:12:40 +00:00
|
|
|
spinlock_t rd_rsspin; /* protects reservation related vars */
|
2021-02-08 19:44:26 +00:00
|
|
|
struct mutex rd_mutex;
|
2012-07-19 12:12:40 +00:00
|
|
|
struct rb_root rd_rstree; /* multi-block reservation tree */
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
enum gfs2_state_bits {
|
|
|
|
BH_Pinned = BH_PrivateStart,
|
2006-01-30 18:34:10 +00:00
|
|
|
BH_Escaped = BH_PrivateStart + 1,
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
BUFFER_FNS(Pinned, pinned)
|
|
|
|
TAS_BUFFER_FNS(Pinned, pinned)
|
2006-01-30 18:34:10 +00:00
|
|
|
BUFFER_FNS(Escaped, escaped)
|
|
|
|
TAS_BUFFER_FNS(Escaped, escaped)
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
struct gfs2_bufdata {
|
|
|
|
struct buffer_head *bd_bh;
|
|
|
|
struct gfs2_glock *bd_gl;
|
2012-04-16 15:40:56 +00:00
|
|
|
u64 bd_blkno;
|
2007-09-02 14:39:43 +00:00
|
|
|
|
2012-05-01 16:00:34 +00:00
|
|
|
struct list_head bd_list;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
GFS2: replace gfs2_ail structure with gfs2_trans
In order to allow transactions and log flushes to happen at the same
time, gfs2 needs to move the transaction accounting and active items
list code into the gfs2_trans structure. As a first step toward this,
this patch removes the gfs2_ail structure, and handles the active items
list in the gfs_trans structure. This keeps gfs2 from allocating an ail
structure on log flushes, and gives us a struture that can later be used
to store the transaction accounting outside of the gfs2 superblock
structure.
With this patch, at the end of a transaction, gfs2 will add the
gfs2_trans structure to the superblock if there is not one already.
This structure now has the active items fields that were previously in
gfs2_ail. This is not necessary in the case where the transaction was
simply used to add revokes, since these are never written outside of the
journal, and thus, don't need an active items list.
Also, in order to make sure that the transaction structure is not
removed while it's still in use by gfs2_trans_end, unlocking the
sd_log_flush_lock has to happen slightly later in ending the
transaction.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2013-04-06 01:31:46 +00:00
|
|
|
struct gfs2_trans *bd_tr;
|
2006-01-16 16:50:04 +00:00
|
|
|
struct list_head bd_ail_st_list;
|
|
|
|
struct list_head bd_ail_gl_list;
|
|
|
|
};
|
|
|
|
|
2009-01-12 10:43:39 +00:00
|
|
|
/*
|
|
|
|
* Internally, we prefix things with gdlm_ and GDLM_ (for gfs-dlm) since a
|
|
|
|
* prefix of lock_dlm_ gets awkward.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define GDLM_STRNAME_BYTES 25
|
|
|
|
#define GDLM_LVB_SIZE 32
|
|
|
|
|
2012-01-09 22:18:05 +00:00
|
|
|
/*
|
|
|
|
* ls_recover_flags:
|
|
|
|
*
|
|
|
|
* DFL_BLOCK_LOCKS: dlm is in recovery and will grant locks that had been
|
|
|
|
* held by failed nodes whose journals need recovery. Those locks should
|
|
|
|
* only be used for journal recovery until the journal recovery is done.
|
|
|
|
* This is set by the dlm recover_prep callback and cleared by the
|
|
|
|
* gfs2_control thread when journal recovery is complete. To avoid
|
|
|
|
* races between recover_prep setting and gfs2_control clearing, recover_spin
|
|
|
|
* is held while changing this bit and reading/writing recover_block
|
|
|
|
* and recover_start.
|
|
|
|
*
|
|
|
|
* DFL_NO_DLM_OPS: dlm lockspace ops/callbacks are not being used.
|
|
|
|
*
|
|
|
|
* DFL_FIRST_MOUNT: this node is the first to mount this fs and is doing
|
|
|
|
* recovery of all journals before allowing other nodes to mount the fs.
|
|
|
|
* This is cleared when FIRST_MOUNT_DONE is set.
|
|
|
|
*
|
|
|
|
* DFL_FIRST_MOUNT_DONE: this node was the first mounter, and has finished
|
|
|
|
* recovery of all journals, and now allows other nodes to mount the fs.
|
|
|
|
*
|
|
|
|
* DFL_MOUNT_DONE: gdlm_mount has completed successfully and cleared
|
|
|
|
* BLOCK_LOCKS for the first time. The gfs2_control thread should now
|
|
|
|
* control clearing BLOCK_LOCKS for further recoveries.
|
|
|
|
*
|
|
|
|
* DFL_UNMOUNT: gdlm_unmount sets to keep sdp off gfs2_control_wq.
|
|
|
|
*
|
|
|
|
* DFL_DLM_RECOVERY: set while dlm is in recovery, between recover_prep()
|
|
|
|
* and recover_done(), i.e. set while recover_block == recover_start.
|
|
|
|
*/
|
|
|
|
|
2009-01-12 10:43:39 +00:00
|
|
|
enum {
|
|
|
|
DFL_BLOCK_LOCKS = 0,
|
2012-01-09 22:18:05 +00:00
|
|
|
DFL_NO_DLM_OPS = 1,
|
|
|
|
DFL_FIRST_MOUNT = 2,
|
|
|
|
DFL_FIRST_MOUNT_DONE = 3,
|
|
|
|
DFL_MOUNT_DONE = 4,
|
|
|
|
DFL_UNMOUNT = 5,
|
|
|
|
DFL_DLM_RECOVERY = 6,
|
2009-01-12 10:43:39 +00:00
|
|
|
};
|
|
|
|
|
2017-03-16 13:54:57 +00:00
|
|
|
/*
|
|
|
|
* We are using struct lm_lockname as an rhashtable key. Avoid holes within
|
|
|
|
* the struct; padding at the end is fine.
|
|
|
|
*/
|
2009-01-12 10:43:39 +00:00
|
|
|
struct lm_lockname {
|
|
|
|
u64 ln_number;
|
2017-03-16 13:54:57 +00:00
|
|
|
struct gfs2_sbd *ln_sbd;
|
2009-01-12 10:43:39 +00:00
|
|
|
unsigned int ln_type;
|
2017-03-16 13:54:57 +00:00
|
|
|
};
|
2009-01-12 10:43:39 +00:00
|
|
|
|
|
|
|
#define lm_name_equal(name1, name2) \
|
2015-03-16 16:52:05 +00:00
|
|
|
(((name1)->ln_number == (name2)->ln_number) && \
|
|
|
|
((name1)->ln_type == (name2)->ln_type) && \
|
|
|
|
((name1)->ln_sbd == (name2)->ln_sbd))
|
2009-01-12 10:43:39 +00:00
|
|
|
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_glock_operations {
|
2019-11-13 20:09:28 +00:00
|
|
|
int (*go_sync) (struct gfs2_glock *gl);
|
2021-03-19 11:56:44 +00:00
|
|
|
int (*go_xmote_bh)(struct gfs2_glock *gl);
|
2006-11-20 15:37:45 +00:00
|
|
|
void (*go_inval) (struct gfs2_glock *gl, int flags);
|
2008-11-20 13:39:47 +00:00
|
|
|
int (*go_demote_ok) (const struct gfs2_glock *gl);
|
2022-06-10 10:06:06 +00:00
|
|
|
int (*go_instantiate) (struct gfs2_glock *gl);
|
2022-06-10 09:42:33 +00:00
|
|
|
int (*go_held)(struct gfs2_holder *gh);
|
2023-06-21 20:32:06 +00:00
|
|
|
void (*go_dump)(struct seq_file *seq, const struct gfs2_glock *gl,
|
2019-05-09 14:21:48 +00:00
|
|
|
const char *fs_id_buf);
|
2013-04-10 09:26:55 +00:00
|
|
|
void (*go_callback)(struct gfs2_glock *gl, bool remote);
|
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-28 19:23:45 +00:00
|
|
|
void (*go_free)(struct gfs2_glock *gl);
|
2020-11-23 15:53:35 +00:00
|
|
|
const int go_subclass;
|
2006-08-30 13:30:00 +00:00
|
|
|
const int go_type;
|
2009-12-08 12:12:13 +00:00
|
|
|
const unsigned long go_flags;
|
gfs2: Allow some glocks to be used during withdraw
We need to allow some glocks to be enqueued, dequeued, promoted, and demoted
when we're withdrawn. For example, to maintain metadata integrity, we should
disallow the use of inode and rgrp glocks when withdrawn. Other glocks, like
iopen or the transaction glocks may be safely used because none of their
metadata goes through the journal. So in general, we should disallow all
glocks with an address space, and allow all the others. One exception is:
we need to allow our active journal to be demoted so others may recover it.
Allowing glocks after withdraw gives us the ability to take appropriate
action (in a following patch) to have our journal properly replayed by
another node rather than just abandoning the current transactions and
pretending nothing bad happened, leaving the other nodes free to modify
the blocks we had in our journal, which may result in file system
corruption.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2019-06-13 18:28:45 +00:00
|
|
|
#define GLOF_ASPACE 1 /* address space attached */
|
|
|
|
#define GLOF_LVB 2 /* Lock Value Block attached */
|
|
|
|
#define GLOF_LRU 4 /* LRU managed */
|
|
|
|
#define GLOF_NONDISK 8 /* not I/O related */
|
2006-01-16 16:50:04 +00: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 10:38:36 +00:00
|
|
|
enum {
|
|
|
|
GFS2_LKS_SRTT = 0, /* Non blocking smoothed round trip time */
|
|
|
|
GFS2_LKS_SRTTVAR = 1, /* Non blocking smoothed variance */
|
|
|
|
GFS2_LKS_SRTTB = 2, /* Blocking smoothed round trip time */
|
|
|
|
GFS2_LKS_SRTTVARB = 3, /* Blocking smoothed variance */
|
|
|
|
GFS2_LKS_SIRT = 4, /* Smoothed Inter-request time */
|
|
|
|
GFS2_LKS_SIRTVAR = 5, /* Smoothed Inter-request variance */
|
|
|
|
GFS2_LKS_DCOUNT = 6, /* Count of dlm requests */
|
|
|
|
GFS2_LKS_QCOUNT = 7, /* Count of gfs2_holder queues */
|
|
|
|
GFS2_NR_LKSTATS
|
|
|
|
};
|
|
|
|
|
|
|
|
struct gfs2_lkstats {
|
2015-08-27 17:51:45 +00:00
|
|
|
u64 stats[GFS2_NR_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 10:38:36 +00:00
|
|
|
};
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
enum {
|
|
|
|
/* States */
|
2008-05-21 16:03:22 +00:00
|
|
|
HIF_HOLDER = 6, /* Set for gh that "holds" the glock */
|
2007-01-17 15:33:23 +00:00
|
|
|
HIF_WAIT = 10,
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct gfs2_holder {
|
|
|
|
struct list_head gh_list;
|
|
|
|
|
|
|
|
struct gfs2_glock *gh_gl;
|
2008-02-07 08:13:19 +00:00
|
|
|
struct pid *gh_owner_pid;
|
2015-07-24 14:45:43 +00:00
|
|
|
u16 gh_flags;
|
|
|
|
u16 gh_state;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
int gh_error;
|
2008-05-21 16:03:22 +00:00
|
|
|
unsigned long gh_iflags; /* HIF_... */
|
2006-03-29 19:36:49 +00:00
|
|
|
unsigned long gh_ip;
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
2014-09-10 19:22:51 +00:00
|
|
|
/* Number of quota types we support */
|
|
|
|
#define GFS2_MAXQUOTAS 2
|
|
|
|
|
2015-10-26 15:40:28 +00:00
|
|
|
struct gfs2_qadata { /* quota allocation data */
|
|
|
|
/* Quota stuff */
|
|
|
|
struct gfs2_quota_data *qa_qd[2 * GFS2_MAXQUOTAS];
|
|
|
|
struct gfs2_holder qa_qd_ghs[2 * GFS2_MAXQUOTAS];
|
|
|
|
unsigned int qa_qd_num;
|
2020-02-27 18:47:53 +00:00
|
|
|
int qa_ref;
|
2015-10-26 15:40:28 +00:00
|
|
|
};
|
|
|
|
|
2012-07-19 12:12:40 +00:00
|
|
|
/* Resource group multi-block reservation, in order of appearance:
|
|
|
|
|
|
|
|
Step 1. Function prepares to write, allocates a mb, sets the size hint.
|
|
|
|
Step 2. User calls inplace_reserve to target an rgrp, sets the rgrp info
|
|
|
|
Step 3. Function get_local_rgrp locks the rgrp, determines which bits to use
|
|
|
|
Step 4. Bits are assigned from the rgrp based on either the reservation
|
|
|
|
or wherever it can.
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct gfs2_blkreserv {
|
2018-10-11 16:56:40 +00:00
|
|
|
struct rb_node rs_node; /* node within rd_rstree */
|
|
|
|
struct gfs2_rgrpd *rs_rgd;
|
2020-10-22 18:34:29 +00:00
|
|
|
u64 rs_start;
|
|
|
|
u32 rs_requested;
|
2018-10-02 13:59:54 +00:00
|
|
|
u32 rs_reserved; /* number of reserved blocks */
|
2012-07-19 12:12:40 +00:00
|
|
|
};
|
|
|
|
|
2013-10-02 10:13:25 +00:00
|
|
|
/*
|
|
|
|
* Allocation parameters
|
|
|
|
* @target: The number of blocks we'd ideally like to allocate
|
|
|
|
* @aflags: The flags (e.g. Orlov flag)
|
|
|
|
*
|
|
|
|
* The intent is to gradually expand this structure over time in
|
|
|
|
* order to give more information, e.g. alignment, min extent size
|
|
|
|
* to the allocation code.
|
|
|
|
*/
|
|
|
|
struct gfs2_alloc_parms {
|
2015-03-18 17:03:41 +00:00
|
|
|
u64 target;
|
2015-03-18 17:04:37 +00:00
|
|
|
u32 min_target;
|
2013-10-02 10:13:25 +00:00
|
|
|
u32 aflags;
|
2015-03-18 17:04:37 +00:00
|
|
|
u64 allowed;
|
2013-10-02 10:13:25 +00:00
|
|
|
};
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
enum {
|
2008-05-21 16:03:22 +00:00
|
|
|
GLF_LOCK = 1,
|
gfs2: fix GL_SKIP node_scope problems
Before this patch, when a glock was locked, the very first holder on the
queue would unlock the lockref and call the go_instantiate glops function
(if one existed), unless GL_SKIP was specified. When we introduced the new
node-scope concept, we allowed multiple holders to lock glocks in EX mode
and share the lock.
But node-scope introduced a new problem: if the first holder has GL_SKIP
and the next one does NOT, since it is not the first holder on the queue,
the go_instantiate op was not called. Eventually the GL_SKIP holder may
call the instantiate sub-function (e.g. gfs2_rgrp_bh_get) but there was
still a window of time in which another non-GL_SKIP holder assumes the
instantiate function had been called by the first holder. In the case of
rgrp glocks, this led to a NULL pointer dereference on the buffer_heads.
This patch tries to fix the problem by introducing two new glock flags:
GLF_INSTANTIATE_NEEDED, which keeps track of when the instantiate function
needs to be called to "fill in" or "read in" the object before it is
referenced.
GLF_INSTANTIATE_IN_PROG which is used to determine when a process is
in the process of reading in the object. Whenever a function needs to
reference the object, it checks the GLF_INSTANTIATE_NEEDED flag, and if
set, it sets GLF_INSTANTIATE_IN_PROG and calls the glops "go_instantiate"
function.
As before, the gl_lockref spin_lock is unlocked during the IO operation,
which may take a relatively long amount of time to complete. While
unlocked, if another process determines go_instantiate is still needed,
it sees GLF_INSTANTIATE_IN_PROG is set, and waits for the go_instantiate
glop operation to be completed. Once GLF_INSTANTIATE_IN_PROG is cleared,
it needs to check GLF_INSTANTIATE_NEEDED again because the other process's
go_instantiate operation may not have been successful.
Functions that previously called the instantiate sub-functions now call
directly into gfs2_instantiate so the new bits are managed properly.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2021-10-06 14:29:18 +00:00
|
|
|
GLF_INSTANTIATE_NEEDED = 2, /* needs instantiate */
|
2008-05-21 16:03:22 +00:00
|
|
|
GLF_DEMOTE = 3,
|
|
|
|
GLF_PENDING_DEMOTE = 4,
|
|
|
|
GLF_DEMOTE_IN_PROGRESS = 5,
|
|
|
|
GLF_DIRTY = 6,
|
|
|
|
GLF_LFLUSH = 7,
|
|
|
|
GLF_INVALIDATE_IN_PROGRESS = 8,
|
|
|
|
GLF_REPLY_PENDING = 9,
|
2009-01-12 10:43:39 +00:00
|
|
|
GLF_INITIAL = 10,
|
|
|
|
GLF_FROZEN = 11,
|
gfs2: fix GL_SKIP node_scope problems
Before this patch, when a glock was locked, the very first holder on the
queue would unlock the lockref and call the go_instantiate glops function
(if one existed), unless GL_SKIP was specified. When we introduced the new
node-scope concept, we allowed multiple holders to lock glocks in EX mode
and share the lock.
But node-scope introduced a new problem: if the first holder has GL_SKIP
and the next one does NOT, since it is not the first holder on the queue,
the go_instantiate op was not called. Eventually the GL_SKIP holder may
call the instantiate sub-function (e.g. gfs2_rgrp_bh_get) but there was
still a window of time in which another non-GL_SKIP holder assumes the
instantiate function had been called by the first holder. In the case of
rgrp glocks, this led to a NULL pointer dereference on the buffer_heads.
This patch tries to fix the problem by introducing two new glock flags:
GLF_INSTANTIATE_NEEDED, which keeps track of when the instantiate function
needs to be called to "fill in" or "read in" the object before it is
referenced.
GLF_INSTANTIATE_IN_PROG which is used to determine when a process is
in the process of reading in the object. Whenever a function needs to
reference the object, it checks the GLF_INSTANTIATE_NEEDED flag, and if
set, it sets GLF_INSTANTIATE_IN_PROG and calls the glops "go_instantiate"
function.
As before, the gl_lockref spin_lock is unlocked during the IO operation,
which may take a relatively long amount of time to complete. While
unlocked, if another process determines go_instantiate is still needed,
it sees GLF_INSTANTIATE_IN_PROG is set, and waits for the go_instantiate
glop operation to be completed. Once GLF_INSTANTIATE_IN_PROG is cleared,
it needs to check GLF_INSTANTIATE_NEEDED again because the other process's
go_instantiate operation may not have been successful.
Functions that previously called the instantiate sub-functions now call
directly into gfs2_instantiate so the new bits are managed properly.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2021-10-06 14:29:18 +00:00
|
|
|
GLF_INSTANTIATE_IN_PROG = 12, /* instantiate happening now */
|
2011-04-14 13:09:52 +00:00
|
|
|
GLF_LRU = 13,
|
|
|
|
GLF_OBJECT = 14, /* Used only for tracing */
|
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 10:38:36 +00:00
|
|
|
GLF_BLOCKING = 15,
|
2022-12-09 17:28:20 +00:00
|
|
|
GLF_FREEING = 16, /* Wait for glock to be freed */
|
2022-12-20 23:52:51 +00:00
|
|
|
GLF_TRY_TO_EVICT = 17, /* iopen glocks only */
|
|
|
|
GLF_VERIFY_EVICT = 18, /* iopen glocks only */
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct gfs2_glock {
|
|
|
|
unsigned long gl_flags; /* GLF_... */
|
|
|
|
struct lm_lockname gl_name;
|
|
|
|
|
2013-10-15 14:18:08 +00:00
|
|
|
struct lockref gl_lockref;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2015-10-29 15:58:09 +00:00
|
|
|
/* State fields protected by gl_lockref.lock */
|
2010-11-30 15:49:31 +00:00
|
|
|
unsigned int gl_state:2, /* Current state */
|
|
|
|
gl_target:2, /* Target state */
|
|
|
|
gl_demote_state:2, /* State requested by remote node */
|
|
|
|
gl_req:2, /* State in last dlm request */
|
|
|
|
gl_reply:8; /* Last reply from the dlm */
|
|
|
|
|
2007-03-16 09:40:31 +00:00
|
|
|
unsigned long gl_demote_time; /* time of first demote request */
|
2011-06-15 15:41:48 +00:00
|
|
|
long gl_hold_time;
|
2006-01-16 16:50:04 +00:00
|
|
|
struct list_head gl_holders;
|
|
|
|
|
2006-08-30 13:30:00 +00:00
|
|
|
const struct gfs2_glock_operations *gl_ops;
|
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 10:38:36 +00:00
|
|
|
ktime_t gl_dstamp;
|
|
|
|
struct gfs2_lkstats gl_stats;
|
2009-01-12 10:43:39 +00:00
|
|
|
struct dlm_lksb gl_lksb;
|
[GFS2] delay glock demote for a minimum hold time
When a lot of IO, with some distributed mmap IO, is run on a GFS2 filesystem in
a cluster, it will deadlock. The reason is that do_no_page() will repeatedly
call gfs2_sharewrite_nopage(), because each node keeps giving up the glock
too early, and is forced to call unmap_mapping_range(). This bumps the
mapping->truncate_count sequence count, forcing do_no_page() to retry. This
patch institutes a minimum glock hold time a tenth a second. This insures
that even in heavy contention cases, the node has enough time to get some
useful work done before it gives up the glock.
A second issue is that when gfs2_glock_dq() is called from within a page fault
to demote a lock, and the associated page needs to be written out, it will
try to acqire a lock on it, but it has already been locked at a higher level.
This patch puts makes gfs2_glock_dq() use the work queue as well, to avoid this
issue. This is the same patch as Steve Whitehouse originally proposed to fix
this issue, execpt that gfs2_glock_dq() now grabs a reference to the glock
before it queues up the work on it.
Signed-off-by: Benjamin E. Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2007-08-23 18:19:05 +00:00
|
|
|
unsigned long gl_tchange;
|
2006-01-16 16:50:04 +00:00
|
|
|
void *gl_object;
|
|
|
|
|
2008-11-20 13:39:47 +00:00
|
|
|
struct list_head gl_lru;
|
2006-01-16 16:50:04 +00:00
|
|
|
struct list_head gl_ail_list;
|
|
|
|
atomic_t gl_ail_count;
|
2019-06-06 12:33:38 +00:00
|
|
|
atomic_t gl_revokes;
|
[GFS2] delay glock demote for a minimum hold time
When a lot of IO, with some distributed mmap IO, is run on a GFS2 filesystem in
a cluster, it will deadlock. The reason is that do_no_page() will repeatedly
call gfs2_sharewrite_nopage(), because each node keeps giving up the glock
too early, and is forced to call unmap_mapping_range(). This bumps the
mapping->truncate_count sequence count, forcing do_no_page() to retry. This
patch institutes a minimum glock hold time a tenth a second. This insures
that even in heavy contention cases, the node has enough time to get some
useful work done before it gives up the glock.
A second issue is that when gfs2_glock_dq() is called from within a page fault
to demote a lock, and the associated page needs to be written out, it will
try to acqire a lock on it, but it has already been locked at a higher level.
This patch puts makes gfs2_glock_dq() use the work queue as well, to avoid this
issue. This is the same patch as Steve Whitehouse originally proposed to fix
this issue, execpt that gfs2_glock_dq() now grabs a reference to the glock
before it queues up the work on it.
Signed-off-by: Benjamin E. Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2007-08-23 18:19:05 +00:00
|
|
|
struct delayed_work gl_work;
|
2020-10-15 16:07:26 +00:00
|
|
|
/* For iopen glocks only */
|
|
|
|
struct {
|
|
|
|
struct delayed_work gl_delete;
|
|
|
|
u64 gl_no_formal_ino;
|
2013-12-06 10:16:14 +00:00
|
|
|
};
|
2017-07-07 18:22:05 +00:00
|
|
|
struct rcu_head gl_rcu;
|
2015-03-16 16:02:46 +00:00
|
|
|
struct rhash_head gl_node;
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
GIF_QD_LOCKED = 1,
|
2011-08-02 12:17:27 +00:00
|
|
|
GIF_ALLOC_FAILED = 2,
|
2006-01-16 16:50:04 +00:00
|
|
|
GIF_SW_PAGED = 3,
|
2014-03-31 15:33:17 +00:00
|
|
|
GIF_FREE_VFS_INODE = 5,
|
2017-06-30 12:47:15 +00:00
|
|
|
GIF_GLOP_PENDING = 6,
|
2020-01-13 21:16:17 +00:00
|
|
|
GIF_DEFERRED_DELETE = 7,
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct gfs2_inode {
|
2006-05-18 20:25:27 +00:00
|
|
|
struct inode i_inode;
|
2007-05-15 14:37:50 +00:00
|
|
|
u64 i_no_addr;
|
|
|
|
u64 i_no_formal_ino;
|
2008-11-03 13:39:46 +00:00
|
|
|
u64 i_generation;
|
2008-11-03 14:28:42 +00:00
|
|
|
u64 i_eattr;
|
2006-01-16 16:50:04 +00:00
|
|
|
unsigned long i_flags; /* GIF_... */
|
2021-08-25 19:54:18 +00:00
|
|
|
struct gfs2_glock *i_gl;
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_holder i_iopen_gh;
|
2015-10-26 15:40:28 +00:00
|
|
|
struct gfs2_qadata *i_qadata; /* quota allocation data */
|
2018-08-30 15:01:50 +00:00
|
|
|
struct gfs2_holder i_rgd_gh;
|
2015-07-16 13:28:04 +00:00
|
|
|
struct gfs2_blkreserv i_res; /* rgrp multi-block reservation */
|
2008-02-06 09:25:45 +00:00
|
|
|
u64 i_goal; /* goal block for allocations */
|
2018-08-30 15:01:50 +00:00
|
|
|
atomic_t i_sizehint; /* hint of the write size */
|
2006-01-16 16:50:04 +00:00
|
|
|
struct rw_semaphore i_rw_mutex;
|
2013-01-28 09:30:07 +00:00
|
|
|
struct list_head i_ordered;
|
2011-06-15 09:29:37 +00:00
|
|
|
__be64 *i_hash_cache;
|
2008-11-03 13:59:19 +00:00
|
|
|
u32 i_entries;
|
2008-11-04 10:05:22 +00:00
|
|
|
u32 i_diskflags;
|
2008-01-28 10:37:35 +00:00
|
|
|
u8 i_height;
|
2008-02-01 09:23:44 +00:00
|
|
|
u8 i_depth;
|
2015-11-11 21:00:35 +00:00
|
|
|
u16 i_rahead;
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
2006-06-14 19:32:57 +00:00
|
|
|
/*
|
|
|
|
* Since i_inode is the first element of struct gfs2_inode,
|
|
|
|
* this is effectively a cast.
|
|
|
|
*/
|
2006-05-18 20:25:27 +00:00
|
|
|
static inline struct gfs2_inode *GFS2_I(struct inode *inode)
|
|
|
|
{
|
|
|
|
return container_of(inode, struct gfs2_inode, i_inode);
|
|
|
|
}
|
|
|
|
|
2007-10-17 07:35:19 +00:00
|
|
|
static inline struct gfs2_sbd *GFS2_SB(const struct inode *inode)
|
2006-06-14 19:32:57 +00:00
|
|
|
{
|
|
|
|
return inode->i_sb->s_fs_info;
|
|
|
|
}
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_file {
|
2006-02-21 12:51:39 +00:00
|
|
|
struct mutex f_fl_mutex;
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_holder f_fl_gh;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct gfs2_revoke_replay {
|
|
|
|
struct list_head rr_list;
|
2006-09-04 16:49:07 +00:00
|
|
|
u64 rr_blkno;
|
2006-01-16 16:50:04 +00:00
|
|
|
unsigned int rr_where;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
QDF_CHANGE = 1,
|
|
|
|
QDF_LOCKED = 2,
|
2011-03-08 15:40:42 +00:00
|
|
|
QDF_REFRESH = 3,
|
2015-06-02 16:03:04 +00:00
|
|
|
QDF_QMSG_QUIET = 4,
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct gfs2_quota_data {
|
2013-12-12 10:47:59 +00:00
|
|
|
struct hlist_bl_node qd_hlist;
|
2006-01-16 16:50:04 +00:00
|
|
|
struct list_head qd_list;
|
2013-11-04 10:15:08 +00:00
|
|
|
struct kqid qd_id;
|
2013-12-12 10:47:59 +00:00
|
|
|
struct gfs2_sbd *qd_sbd;
|
2013-11-01 18:52:06 +00:00
|
|
|
struct lockref qd_lockref;
|
2013-11-04 10:15:08 +00:00
|
|
|
struct list_head qd_lru;
|
2013-12-12 10:47:59 +00:00
|
|
|
unsigned qd_hash;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
unsigned long qd_flags; /* QDF_... */
|
|
|
|
|
2006-09-04 16:49:07 +00:00
|
|
|
s64 qd_change;
|
|
|
|
s64 qd_change_sync;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
unsigned int qd_slot;
|
2023-06-16 18:22:04 +00:00
|
|
|
unsigned int qd_slot_ref;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
struct buffer_head *qd_bh;
|
|
|
|
struct gfs2_quota_change *qd_bh_qc;
|
|
|
|
unsigned int qd_bh_count;
|
|
|
|
|
|
|
|
struct gfs2_glock *qd_gl;
|
|
|
|
struct gfs2_quota_lvb qd_qb;
|
|
|
|
|
2006-09-04 16:49:07 +00:00
|
|
|
u64 qd_sync_gen;
|
2006-01-16 16:50:04 +00:00
|
|
|
unsigned long qd_last_warn;
|
2013-12-12 10:47:59 +00:00
|
|
|
struct rcu_head qd_rcu;
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
2017-01-25 17:50:47 +00:00
|
|
|
enum {
|
|
|
|
TR_TOUCHED = 1,
|
|
|
|
TR_ATTACHED = 2,
|
2021-01-29 15:45:33 +00:00
|
|
|
TR_ONSTACK = 3,
|
2017-01-25 17:50:47 +00:00
|
|
|
};
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_trans {
|
2006-03-29 19:36:49 +00:00
|
|
|
unsigned long tr_ip;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
unsigned int tr_blocks;
|
|
|
|
unsigned int tr_revokes;
|
|
|
|
unsigned int tr_reserved;
|
2017-01-25 17:50:47 +00:00
|
|
|
unsigned long tr_flags;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
unsigned int tr_num_buf_new;
|
[GFS2] assertion failure after writing to journaled file, umount
This patch passes all my nasty tests that were causing the code to
fail under one circumstance or another. Here is a complete summary
of all changes from today's git tree, in order of appearance:
1. There are now separate variables for metadata buffer accounting.
2. Variable sd_log_num_hdrs is no longer needed, since the header
accounting is taken care of by the reserve/refund sequence.
3. Fixed a tiny grammatical problem in a comment.
4. Added a new function "calc_reserved" to calculate the reserved
log space. This isn't entirely necessary, but it has two benefits:
First, it simplifies the gfs2_log_refund function greatly.
Second, it allows for easier debugging because I could sprinkle the
code with calls to this function to make sure the accounting is
proper (by adding asserts and printks) at strategic point of the code.
5. In log_pull_tail there apparently was a kludge to fix up the
accounting based on a "pull" parameter. The buffer accounting is
now done properly, so the kludge was removed.
6. File sync operations were making a call to gfs2_log_flush that
writes another journal header. Since that header was unplanned
for (reserved) by the reserve/refund sequence, the free space had
to be decremented so that when log_pull_tail gets called, the free
space is be adjusted properly. (Did I hear you call that a kludge?
well, maybe, but a lot more justifiable than the one I removed).
7. In the gfs2_log_shutdown code, it optionally syncs the log by
specifying the PULL parameter to log_write_header. I'm not sure
this is necessary anymore. It just seems to me there could be
cases where shutdown is called while there are outstanding log
buffers.
8. In the (data)buf_lo_before_commit functions, I changed some offset
values from being calculated on the fly to being constants. That
simplified some code and we might as well let the compiler do the
calculation once rather than redoing those cycles at run time.
9. This version has my rewritten databuf_lo_add function.
This version is much more like its predecessor, buf_lo_add, which
makes it easier to understand. Again, this might not be necessary,
but it seems as if this one works as well as the previous one,
maybe even better, so I decided to leave it in.
10. In databuf_lo_before_commit, a previous data corruption problem
was caused by going off the end of the buffer. The proper solution
is to have the proper limit in place, rather than stopping earlier.
(Thus my previous attempt to fix it is wrong).
If you don't wrap the buffer, you're stopping too early and that
causes more log buffer accounting problems.
11. In lops.h there are two new (previously mentioned) constants for
figuring out the data offset for the journal buffers.
12. There are also two new functions, buf_limit and databuf_limit to
calculate how many entries will fit in the buffer.
13. In function gfs2_meta_wipe, it needs to distinguish between pinned
metadata buffers and journaled data buffers for proper journal buffer
accounting. It can't use the JDATA gfs2_inode flag because it's
sometimes passed the "real" inode and sometimes the "metadata
inode" and the inode flags will be random bits in a metadata
gfs2_inode. It needs to base its decision on which was passed in.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2007-06-18 19:50:20 +00:00
|
|
|
unsigned int tr_num_databuf_new;
|
2006-01-16 16:50:04 +00:00
|
|
|
unsigned int tr_num_buf_rm;
|
[GFS2] assertion failure after writing to journaled file, umount
This patch passes all my nasty tests that were causing the code to
fail under one circumstance or another. Here is a complete summary
of all changes from today's git tree, in order of appearance:
1. There are now separate variables for metadata buffer accounting.
2. Variable sd_log_num_hdrs is no longer needed, since the header
accounting is taken care of by the reserve/refund sequence.
3. Fixed a tiny grammatical problem in a comment.
4. Added a new function "calc_reserved" to calculate the reserved
log space. This isn't entirely necessary, but it has two benefits:
First, it simplifies the gfs2_log_refund function greatly.
Second, it allows for easier debugging because I could sprinkle the
code with calls to this function to make sure the accounting is
proper (by adding asserts and printks) at strategic point of the code.
5. In log_pull_tail there apparently was a kludge to fix up the
accounting based on a "pull" parameter. The buffer accounting is
now done properly, so the kludge was removed.
6. File sync operations were making a call to gfs2_log_flush that
writes another journal header. Since that header was unplanned
for (reserved) by the reserve/refund sequence, the free space had
to be decremented so that when log_pull_tail gets called, the free
space is be adjusted properly. (Did I hear you call that a kludge?
well, maybe, but a lot more justifiable than the one I removed).
7. In the gfs2_log_shutdown code, it optionally syncs the log by
specifying the PULL parameter to log_write_header. I'm not sure
this is necessary anymore. It just seems to me there could be
cases where shutdown is called while there are outstanding log
buffers.
8. In the (data)buf_lo_before_commit functions, I changed some offset
values from being calculated on the fly to being constants. That
simplified some code and we might as well let the compiler do the
calculation once rather than redoing those cycles at run time.
9. This version has my rewritten databuf_lo_add function.
This version is much more like its predecessor, buf_lo_add, which
makes it easier to understand. Again, this might not be necessary,
but it seems as if this one works as well as the previous one,
maybe even better, so I decided to leave it in.
10. In databuf_lo_before_commit, a previous data corruption problem
was caused by going off the end of the buffer. The proper solution
is to have the proper limit in place, rather than stopping earlier.
(Thus my previous attempt to fix it is wrong).
If you don't wrap the buffer, you're stopping too early and that
causes more log buffer accounting problems.
11. In lops.h there are two new (previously mentioned) constants for
figuring out the data offset for the journal buffers.
12. There are also two new functions, buf_limit and databuf_limit to
calculate how many entries will fit in the buffer.
13. In function gfs2_meta_wipe, it needs to distinguish between pinned
metadata buffers and journaled data buffers for proper journal buffer
accounting. It can't use the JDATA gfs2_inode flag because it's
sometimes passed the "real" inode and sometimes the "metadata
inode" and the inode flags will be random bits in a metadata
gfs2_inode. It needs to base its decision on which was passed in.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2007-06-18 19:50:20 +00:00
|
|
|
unsigned int tr_num_databuf_rm;
|
2006-01-16 16:50:04 +00:00
|
|
|
unsigned int tr_num_revoke;
|
|
|
|
|
GFS2: replace gfs2_ail structure with gfs2_trans
In order to allow transactions and log flushes to happen at the same
time, gfs2 needs to move the transaction accounting and active items
list code into the gfs2_trans structure. As a first step toward this,
this patch removes the gfs2_ail structure, and handles the active items
list in the gfs_trans structure. This keeps gfs2 from allocating an ail
structure on log flushes, and gives us a struture that can later be used
to store the transaction accounting outside of the gfs2 superblock
structure.
With this patch, at the end of a transaction, gfs2 will add the
gfs2_trans structure to the superblock if there is not one already.
This structure now has the active items fields that were previously in
gfs2_ail. This is not necessary in the case where the transaction was
simply used to add revokes, since these are never written outside of the
journal, and thus, don't need an active items list.
Also, in order to make sure that the transaction structure is not
removed while it's still in use by gfs2_trans_end, unlocking the
sd_log_flush_lock has to happen slightly later in ending the
transaction.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2013-04-06 01:31:46 +00:00
|
|
|
struct list_head tr_list;
|
2014-02-21 15:22:35 +00:00
|
|
|
struct list_head tr_databuf;
|
|
|
|
struct list_head tr_buf;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
GFS2: replace gfs2_ail structure with gfs2_trans
In order to allow transactions and log flushes to happen at the same
time, gfs2 needs to move the transaction accounting and active items
list code into the gfs2_trans structure. As a first step toward this,
this patch removes the gfs2_ail structure, and handles the active items
list in the gfs_trans structure. This keeps gfs2 from allocating an ail
structure on log flushes, and gives us a struture that can later be used
to store the transaction accounting outside of the gfs2 superblock
structure.
With this patch, at the end of a transaction, gfs2 will add the
gfs2_trans structure to the superblock if there is not one already.
This structure now has the active items fields that were previously in
gfs2_ail. This is not necessary in the case where the transaction was
simply used to add revokes, since these are never written outside of the
journal, and thus, don't need an active items list.
Also, in order to make sure that the transaction structure is not
removed while it's still in use by gfs2_trans_end, unlocking the
sd_log_flush_lock has to happen slightly later in ending the
transaction.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2013-04-06 01:31:46 +00:00
|
|
|
unsigned int tr_first;
|
|
|
|
struct list_head tr_ail1_list;
|
|
|
|
struct list_head tr_ail2_list;
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
2007-12-12 00:49:21 +00:00
|
|
|
struct gfs2_journal_extent {
|
2014-03-03 13:35:57 +00:00
|
|
|
struct list_head list;
|
2007-12-12 00:49:21 +00:00
|
|
|
|
|
|
|
unsigned int lblock; /* First logical block */
|
|
|
|
u64 dblock; /* First disk block */
|
|
|
|
u64 blocks;
|
|
|
|
};
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_jdesc {
|
|
|
|
struct list_head jd_list;
|
2007-12-12 00:49:21 +00:00
|
|
|
struct list_head extent_list;
|
2014-03-03 13:35:57 +00:00
|
|
|
unsigned int nr_extents;
|
2010-07-20 20:09:02 +00:00
|
|
|
struct work_struct jd_work;
|
2006-02-13 12:27:43 +00:00
|
|
|
struct inode *jd_inode;
|
2021-01-21 15:10:26 +00:00
|
|
|
struct bio *jd_log_bio;
|
2009-05-19 09:01:18 +00:00
|
|
|
unsigned long jd_flags;
|
|
|
|
#define JDF_RECOVERY 1
|
2006-01-16 16:50:04 +00:00
|
|
|
unsigned int jd_jid;
|
2019-03-25 15:34:19 +00:00
|
|
|
u32 jd_blocks;
|
2012-01-09 20:29:20 +00:00
|
|
|
int jd_recover_error;
|
2014-03-06 22:19:15 +00:00
|
|
|
/* Replay stuff */
|
|
|
|
|
|
|
|
unsigned int jd_found_blocks;
|
|
|
|
unsigned int jd_found_revokes;
|
|
|
|
unsigned int jd_replayed_blocks;
|
|
|
|
|
|
|
|
struct list_head jd_revoke_list;
|
|
|
|
unsigned int jd_replay_tail;
|
|
|
|
|
gfs2: Allow some glocks to be used during withdraw
We need to allow some glocks to be enqueued, dequeued, promoted, and demoted
when we're withdrawn. For example, to maintain metadata integrity, we should
disallow the use of inode and rgrp glocks when withdrawn. Other glocks, like
iopen or the transaction glocks may be safely used because none of their
metadata goes through the journal. So in general, we should disallow all
glocks with an address space, and allow all the others. One exception is:
we need to allow our active journal to be demoted so others may recover it.
Allowing glocks after withdraw gives us the ability to take appropriate
action (in a following patch) to have our journal properly replayed by
another node rather than just abandoning the current transactions and
pretending nothing bad happened, leaving the other nodes free to modify
the blocks we had in our journal, which may result in file system
corruption.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2019-06-13 18:28:45 +00:00
|
|
|
u64 jd_no_addr;
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
2007-06-01 13:11:58 +00:00
|
|
|
struct gfs2_statfs_change_host {
|
|
|
|
s64 sc_total;
|
|
|
|
s64 sc_free;
|
|
|
|
s64 sc_dinodes;
|
|
|
|
};
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
#define GFS2_QUOTA_DEFAULT GFS2_QUOTA_OFF
|
|
|
|
#define GFS2_QUOTA_OFF 0
|
|
|
|
#define GFS2_QUOTA_ACCOUNT 1
|
|
|
|
#define GFS2_QUOTA_ON 2
|
2023-06-28 18:52:42 +00:00
|
|
|
#define GFS2_QUOTA_QUIET 3 /* on but not complaining */
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
#define GFS2_DATA_DEFAULT GFS2_DATA_ORDERED
|
|
|
|
#define GFS2_DATA_WRITEBACK 1
|
|
|
|
#define GFS2_DATA_ORDERED 2
|
|
|
|
|
2009-08-24 09:44:18 +00:00
|
|
|
#define GFS2_ERRORS_DEFAULT GFS2_ERRORS_WITHDRAW
|
|
|
|
#define GFS2_ERRORS_WITHDRAW 0
|
|
|
|
#define GFS2_ERRORS_CONTINUE 1 /* place holder for future feature */
|
|
|
|
#define GFS2_ERRORS_RO 2 /* place holder for future feature */
|
|
|
|
#define GFS2_ERRORS_PANIC 3
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_args {
|
2008-09-18 12:49:32 +00:00
|
|
|
char ar_lockproto[GFS2_LOCKNAME_LEN]; /* Name of the Lock Protocol */
|
|
|
|
char ar_locktable[GFS2_LOCKNAME_LEN]; /* Name of the Lock Table */
|
|
|
|
char ar_hostdata[GFS2_LOCKNAME_LEN]; /* Host specific data */
|
|
|
|
unsigned int ar_spectator:1; /* Don't get a journal */
|
|
|
|
unsigned int ar_localflocks:1; /* Let the VFS do flock|fcntl */
|
|
|
|
unsigned int ar_debug:1; /* Oops on errors */
|
|
|
|
unsigned int ar_posix_acl:1; /* Enable posix acls */
|
|
|
|
unsigned int ar_quota:2; /* off/account/on */
|
|
|
|
unsigned int ar_suiddir:1; /* suiddir support */
|
|
|
|
unsigned int ar_data:2; /* ordered/writeback */
|
|
|
|
unsigned int ar_meta:1; /* mount metafs */
|
2009-02-09 09:25:01 +00:00
|
|
|
unsigned int ar_discard:1; /* discard requests */
|
2009-08-24 09:44:18 +00:00
|
|
|
unsigned int ar_errors:2; /* errors=withdraw | panic */
|
2009-10-30 07:03:27 +00:00
|
|
|
unsigned int ar_nobarrier:1; /* do not send barriers */
|
GFS2: Use lvbs for storing rgrp information with mount option
Instead of reading in the resource groups when gfs2 is checking
for free space to allocate from, gfs2 can store the necessary infromation
in the resource group's lvb. Also, instead of searching for unlinked
inodes in every resource group that's checked for free space, gfs2 can
store the number of unlinked but inodes in the lvb, and only check for
unlinked inodes if it will find some.
The first time a resource group is locked, the lvb must initialized.
Since this involves counting the unlinked inodes in the resource group,
this takes a little extra time. But after that, if the resource group
is locked with GL_SKIP, the buffer head won't be read in unless it's
actually needed.
Enabling the resource groups lvbs is done via the rgrplvb mount option. If
this option isn't set, the lvbs will still be set and updated, but they won't
be verfied or used by the filesystem. To safely turn on this option, all of
the nodes mounting the filesystem must be running code with this patch, and
the filesystem must have been completely unmounted since they were updated.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2012-05-30 04:01:09 +00:00
|
|
|
unsigned int ar_rgrplvb:1; /* use lvbs for rgrp info */
|
2021-02-05 17:10:17 +00:00
|
|
|
unsigned int ar_got_rgrplvb:1; /* Was the rgrplvb opt given? */
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 14:46:55 +00:00
|
|
|
unsigned int ar_loccookie:1; /* use location based readdir
|
|
|
|
cookies */
|
2019-03-27 14:46:00 +00:00
|
|
|
s32 ar_commit; /* Commit interval */
|
|
|
|
s32 ar_statfs_quantum; /* The fast statfs interval */
|
|
|
|
s32 ar_quota_quantum; /* The quota interval */
|
|
|
|
s32 ar_statfs_percent; /* The % change to force sync */
|
2006-01-16 16:50:04 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
struct gfs2_tune {
|
|
|
|
spinlock_t gt_spin;
|
|
|
|
|
|
|
|
unsigned int gt_logd_secs;
|
|
|
|
|
|
|
|
unsigned int gt_quota_warn_period; /* Secs between quota warn msgs */
|
|
|
|
unsigned int gt_quota_scale_num; /* Numerator */
|
|
|
|
unsigned int gt_quota_scale_den; /* Denominator */
|
|
|
|
unsigned int gt_quota_quantum; /* Secs between syncs to quota file */
|
|
|
|
unsigned int gt_new_files_jdata;
|
|
|
|
unsigned int gt_max_readahead; /* Max bytes to read-ahead from disk */
|
|
|
|
unsigned int gt_complain_secs;
|
|
|
|
unsigned int gt_statfs_quantum;
|
|
|
|
unsigned int gt_statfs_slow;
|
|
|
|
};
|
|
|
|
|
|
|
|
enum {
|
|
|
|
SDF_JOURNAL_CHECKED = 0,
|
|
|
|
SDF_JOURNAL_LIVE = 1,
|
2019-05-07 18:27:44 +00:00
|
|
|
SDF_WITHDRAWN = 2,
|
2008-09-26 09:23:22 +00:00
|
|
|
SDF_NOBARRIERS = 3,
|
2009-05-19 09:01:18 +00:00
|
|
|
SDF_NORECOVERY = 4,
|
2010-05-06 10:03:29 +00:00
|
|
|
SDF_DEMOTE = 5,
|
2010-06-14 09:01:30 +00:00
|
|
|
SDF_NOJOURNALID = 6,
|
2012-01-09 19:40:06 +00:00
|
|
|
SDF_RORECOVERY = 7, /* read only recovery */
|
2012-11-13 15:58:56 +00:00
|
|
|
SDF_SKIP_DLM_UNLOCK = 8,
|
2017-08-04 17:15:32 +00:00
|
|
|
SDF_FORCE_AIL_FLUSH = 9,
|
2022-11-21 22:09:38 +00:00
|
|
|
SDF_FREEZE_INITIATOR = 10,
|
2019-04-10 17:46:35 +00:00
|
|
|
SDF_WITHDRAWING = 11, /* Will withdraw eventually */
|
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-28 19:23:45 +00:00
|
|
|
SDF_WITHDRAW_IN_PROG = 12, /* Withdraw is in progress */
|
|
|
|
SDF_REMOTE_WITHDRAW = 13, /* Performing remote recovery */
|
|
|
|
SDF_WITHDRAW_RECOVERY = 14, /* Wait for journal recovery when we are
|
|
|
|
withdrawing */
|
2023-08-23 13:53:13 +00:00
|
|
|
SDF_KILL = 15,
|
2023-01-26 19:23:40 +00:00
|
|
|
SDF_EVICTING = 16,
|
2022-08-18 14:12:24 +00:00
|
|
|
SDF_FROZEN = 17,
|
2014-11-14 02:42:04 +00:00
|
|
|
};
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
#define GFS2_FSNAME_LEN 256
|
|
|
|
|
2007-06-01 13:11:58 +00:00
|
|
|
struct gfs2_inum_host {
|
|
|
|
u64 no_formal_ino;
|
|
|
|
u64 no_addr;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct gfs2_sb_host {
|
|
|
|
u32 sb_magic;
|
|
|
|
u32 sb_type;
|
|
|
|
|
|
|
|
u32 sb_fs_format;
|
|
|
|
u32 sb_multihost_format;
|
|
|
|
u32 sb_bsize;
|
|
|
|
u32 sb_bsize_shift;
|
|
|
|
|
|
|
|
struct gfs2_inum_host sb_master_dir;
|
|
|
|
struct gfs2_inum_host sb_root_dir;
|
|
|
|
|
|
|
|
char sb_lockproto[GFS2_LOCKNAME_LEN];
|
|
|
|
char sb_locktable[GFS2_LOCKNAME_LEN];
|
|
|
|
};
|
|
|
|
|
2009-01-12 10:43:39 +00:00
|
|
|
/*
|
|
|
|
* lm_mount() return values
|
|
|
|
*
|
|
|
|
* ls_jid - the journal ID this node should use
|
|
|
|
* ls_first - this node is the first to mount the file system
|
|
|
|
* ls_lockspace - lock module's context for this file system
|
|
|
|
* ls_ops - lock module's functions
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct lm_lockstruct {
|
2010-09-29 14:04:18 +00:00
|
|
|
int ls_jid;
|
2009-01-12 10:43:39 +00:00
|
|
|
unsigned int ls_first;
|
|
|
|
const struct lm_lockops *ls_ops;
|
|
|
|
dlm_lockspace_t *ls_dlm;
|
|
|
|
|
2012-01-09 22:18:05 +00:00
|
|
|
int ls_recover_jid_done; /* These two are deprecated, */
|
|
|
|
int ls_recover_jid_status; /* used previously by gfs_controld */
|
|
|
|
|
|
|
|
struct dlm_lksb ls_mounted_lksb; /* mounted_lock */
|
|
|
|
struct dlm_lksb ls_control_lksb; /* control_lock */
|
|
|
|
char ls_control_lvb[GDLM_LVB_SIZE]; /* control_lock lvb */
|
|
|
|
struct completion ls_sync_wait; /* {control,mounted}_{lock,unlock} */
|
2013-03-05 21:01:47 +00:00
|
|
|
char *ls_lvb_bits;
|
2012-01-09 22:18:05 +00:00
|
|
|
|
|
|
|
spinlock_t ls_recover_spin; /* protects following fields */
|
|
|
|
unsigned long ls_recover_flags; /* DFL_ */
|
|
|
|
uint32_t ls_recover_mount; /* gen in first recover_done cb */
|
|
|
|
uint32_t ls_recover_start; /* gen in last recover_done cb */
|
|
|
|
uint32_t ls_recover_block; /* copy recover_start in last recover_prep */
|
|
|
|
uint32_t ls_recover_size; /* size of recover_submit, recover_result */
|
|
|
|
uint32_t *ls_recover_submit; /* gen in last recover_slot cb per jid */
|
|
|
|
uint32_t *ls_recover_result; /* result of last jid recovery */
|
2009-01-12 10:43:39 +00: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 10:38:36 +00:00
|
|
|
struct gfs2_pcpu_lkstats {
|
|
|
|
/* One struct for each glock type */
|
|
|
|
struct gfs2_lkstats lkstats[10];
|
|
|
|
};
|
|
|
|
|
2020-10-20 20:58:04 +00:00
|
|
|
/* List of local (per node) statfs inodes */
|
|
|
|
struct local_statfs_inode {
|
|
|
|
struct list_head si_list;
|
|
|
|
struct inode *si_sc_inode;
|
|
|
|
unsigned int si_jid; /* journal id this statfs inode corresponds to */
|
|
|
|
};
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_sbd {
|
|
|
|
struct super_block *sd_vfs;
|
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 10:38:36 +00:00
|
|
|
struct gfs2_pcpu_lkstats __percpu *sd_lkstats;
|
2006-01-16 16:50:04 +00:00
|
|
|
struct kobject sd_kobj;
|
2020-10-12 13:13:09 +00:00
|
|
|
struct completion sd_kobj_unregister;
|
2006-01-16 16:50:04 +00:00
|
|
|
unsigned long sd_flags; /* SDF_... */
|
2006-10-14 00:45:02 +00:00
|
|
|
struct gfs2_sb_host sd_sb;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
/* Constants computed on mount */
|
|
|
|
|
2006-09-04 16:49:07 +00:00
|
|
|
u32 sd_fsb2bb;
|
|
|
|
u32 sd_fsb2bb_shift;
|
|
|
|
u32 sd_diptrs; /* Number of pointers in a dinode */
|
|
|
|
u32 sd_inptrs; /* Number of pointers in a indirect block */
|
2019-12-13 14:10:51 +00:00
|
|
|
u32 sd_ldptrs; /* Number of pointers in a log descriptor block */
|
2006-09-04 16:49:07 +00:00
|
|
|
u32 sd_jbsize; /* Size of a journaled data block */
|
|
|
|
u32 sd_hash_bsize; /* sizeof(exhash block) */
|
|
|
|
u32 sd_hash_bsize_shift;
|
|
|
|
u32 sd_hash_ptrs; /* Number of pointers in a hash block */
|
|
|
|
u32 sd_qc_per_block;
|
2012-10-19 12:32:51 +00:00
|
|
|
u32 sd_blocks_per_bitmap;
|
2006-09-04 16:49:07 +00:00
|
|
|
u32 sd_max_dirres; /* Max blocks needed to add a directory entry */
|
|
|
|
u32 sd_max_height; /* Max height of a file's metadata tree */
|
2008-01-28 10:37:35 +00:00
|
|
|
u64 sd_heightsize[GFS2_MAX_META_HEIGHT + 1];
|
gfs2: change gfs2 readdir cookie
gfs2 currently returns 31 bits of filename hash as a cookie that readdir
uses for an offset into the directory. When there are a large number of
directory entries, the likelihood of a collision goes up way too
quickly. GFS2 will now return cookies that are guaranteed unique for a
while, and then fail back to using 30 bits of filename hash.
Specifically, the directory leaf blocks are divided up into chunks based
on the minimum size of a gfs2 directory entry (48 bytes). Each entry's
cookie is based off the chunk where it starts, in the linked list of
leaf blocks that it hashes to (there are 131072 hash buckets). Directory
entries will have unique names until they take reach chunk 8192.
Assuming the largest filenames possible, and the least efficient spacing
possible, this new method will still be able to return unique names when
the previous method has statistically more than a 99% chance of a
collision. The non-unique names it fails back to are guaranteed to not
collide with the unique names.
unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "0"
- 13 bits for the offset
non-unique cookies will be in this format:
- 1 bit "0" to make sure the the returned cookie is positive
- 17 bits for the hash table index
- 1 bit for the mode "1"
- 13 more bits of the name hash
Another benefit of location based cookies, is that once a directory's
exhash table is fully extended (so that multiple hash table indexs do
not use the same leaf blocks), gfs2 can skip sorting the directory
entries until it reaches the non-unique ones, and then it only needs to
sort these. This provides a significant speed up for directory reads of
very large directories.
The only issue is that for these cookies to continue to point to the
correct entry as files are added and removed from the directory, gfs2
must keep the entries at the same offset in the leaf block when they are
split (see my previous patch). This means that until all the nodes in a
cluster are running with code that will split the directory leaf blocks
this way, none of the nodes can use the new cookie code. To deal with
this, gfs2 now has the mount option loccookie, which, if set, will make
it return these new location based cookies. This option must not be set
until all nodes in the cluster are at least running this version of the
kernel code, and you have guaranteed that there are no outstanding
cookies required by other software, such as NFS.
gfs2 uses some of the extra space at the end of the gfs2_dirent
structure to store the calculated readdir cookies. This keeps us from
needing to allocate a seperate array to hold these values. gfs2
recomputes the cookie stored in de_cookie for every readdir call. The
time it takes to do so is small, and if gfs2 expected this value to be
saved on disk, the new code wouldn't work correctly on filesystems
created with an earlier version of gfs2.
One issue with adding de_cookie to the union in the gfs2_dirent
structure is that it caused the union to align itself to a 4 byte
boundary, instead of its previous 2 byte boundary. This changed the
offset of de_rahead. To solve that, I pulled de_rahead out of the union,
since it does not need to be there.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
2015-12-01 14:46:55 +00:00
|
|
|
u32 sd_max_dents_per_leaf; /* Max number of dirents in a leaf block */
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
struct gfs2_args sd_args; /* Mount arguments */
|
|
|
|
struct gfs2_tune sd_tune; /* Filesystem tuning structure */
|
|
|
|
|
|
|
|
/* Lock Stuff */
|
|
|
|
|
|
|
|
struct lm_lockstruct sd_lockstruct;
|
|
|
|
struct gfs2_holder sd_live_gh;
|
|
|
|
struct gfs2_glock *sd_rename_gl;
|
GFS2: remove transaction glock
GFS2 has a transaction glock, which must be grabbed for every
transaction, whose purpose is to deal with freezing the filesystem.
Aside from this involving a large amount of locking, it is very easy to
make the current fsfreeze code hang on unfreezing.
This patch rewrites how gfs2 handles freezing the filesystem. The
transaction glock is removed. In it's place is a freeze glock, which is
cached (but not held) in a shared state by every node in the cluster
when the filesystem is mounted. This lock only needs to be grabbed on
freezing, and actions which need to be safe from freezing, like
recovery.
When a node wants to freeze the filesystem, it grabs this glock
exclusively. When the freeze glock state changes on the nodes (either
from shared to unlocked, or shared to exclusive), the filesystem does a
special log flush. gfs2_log_flush() does all the work for flushing out
the and shutting down the incore log, and then it tries to grab the
freeze glock in a shared state again. Since the filesystem is stuck in
gfs2_log_flush, no new transaction can start, and nothing can be written
to disk. Unfreezing the filesytem simply involes dropping the freeze
glock, allowing gfs2_log_flush() to grab and then release the shared
lock, so it is cached for next time.
However, in order for the unfreezing ioctl to occur, gfs2 needs to get a
shared lock on the filesystem root directory inode to check permissions.
If that glock has already been grabbed exclusively, fsfreeze will be
unable to get the shared lock and unfreeze the filesystem.
In order to allow the unfreeze, this patch makes gfs2 grab a shared lock
on the filesystem root directory during the freeze, and hold it until it
unfreezes the filesystem. The functions which need to grab a shared
lock in order to allow the unfreeze ioctl to be issued now use the lock
grabbed by the freeze code instead.
The freeze and unfreeze code take care to make sure that this shared
lock will not be dropped while another process is using it.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2014-05-02 03:26:55 +00:00
|
|
|
struct gfs2_glock *sd_freeze_gl;
|
2014-11-14 02:42:04 +00:00
|
|
|
struct work_struct sd_freeze_work;
|
2023-08-23 13:49:58 +00:00
|
|
|
wait_queue_head_t sd_kill_wait;
|
gfs2: Use async glocks for rename
Because s_vfs_rename_mutex is not cluster-wide, multiple nodes can
reverse the roles of which directories are "old" and which are "new" for
the purposes of rename. This can cause deadlocks where two nodes end up
waiting for each other.
There can be several layers of directory dependencies across many nodes.
This patch fixes the problem by acquiring all gfs2_rename's inode glocks
asychronously and waiting for all glocks to be acquired. That way all
inodes are locked regardless of the order.
The timeout value for multiple asynchronous glocks is calculated to be
the total of the individual wait times for each glock times two.
Since gfs2_exchange is very similar to gfs2_rename, both functions are
patched in the same way.
A new async glock wait queue, sd_async_glock_wait, keeps a list of
waiters for these events. If gfs2's holder_wake function detects an
async holder, it wakes up any waiters for the event. The waiter only
tests whether any of its requests are still pending.
Since the glocks are sent to dlm asychronously, the wait function needs
to check to see which glocks, if any, were granted.
If a glock is granted by dlm (and therefore held), its minimum hold time
is checked and adjusted as necessary, as other glock grants do.
If the event times out, all glocks held thus far must be dequeued to
resolve any existing deadlocks. Then, if there are any outstanding
locking requests, we need to loop around and wait for dlm to respond to
those requests too. After we release all requests, we return -ESTALE to
the caller (vfs rename) which loops around and retries the request.
Node1 Node2
--------- ---------
1. Enqueue A Enqueue B
2. Enqueue B Enqueue A
3. A granted
6. B granted
7. Wait for B
8. Wait for A
9. A times out (since Node 1 holds A)
10. Dequeue B (since it was granted)
11. Wait for all requests from DLM
12. B Granted (since Node2 released it in step 10)
13. Rename
14. Dequeue A
15. DLM Grants A
16. Dequeue A (due to the timeout and since we
no longer have B held for our task).
17. Dequeue B
18. Return -ESTALE to vfs
19. VFS retries the operation, goto step 1.
This release-all-locks / acquire-all-locks may slow rename / exchange
down as both nodes struggle in the same way and do the same thing.
However, this will only happen when there is contention for the same
inodes, which ought to be rare.
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2019-08-30 17:31:02 +00:00
|
|
|
wait_queue_head_t sd_async_glock_wait;
|
2010-01-25 11:20:19 +00:00
|
|
|
atomic_t sd_glock_disposal;
|
2011-07-11 07:53:30 +00:00
|
|
|
struct completion sd_locking_init;
|
2013-02-13 12:21:40 +00:00
|
|
|
struct completion sd_wdack;
|
2012-01-09 22:18:05 +00:00
|
|
|
struct delayed_work sd_control_work;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
/* Inode Stuff */
|
|
|
|
|
2008-08-08 12:45:13 +00:00
|
|
|
struct dentry *sd_master_dir;
|
|
|
|
struct dentry *sd_root_dir;
|
|
|
|
|
2006-01-30 18:34:10 +00:00
|
|
|
struct inode *sd_jindex;
|
|
|
|
struct inode *sd_statfs_inode;
|
|
|
|
struct inode *sd_sc_inode;
|
2020-10-20 20:58:04 +00:00
|
|
|
struct list_head sd_sc_inodes_list;
|
2006-01-30 18:34:10 +00:00
|
|
|
struct inode *sd_qc_inode;
|
|
|
|
struct inode *sd_rindex;
|
|
|
|
struct inode *sd_quota_inode;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
/* StatFS stuff */
|
|
|
|
|
|
|
|
spinlock_t sd_statfs_spin;
|
2006-10-14 03:43:19 +00:00
|
|
|
struct gfs2_statfs_change_host sd_statfs_master;
|
|
|
|
struct gfs2_statfs_change_host sd_statfs_local;
|
2009-10-20 07:39:44 +00:00
|
|
|
int sd_statfs_force_sync;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
/* Resource group stuff */
|
|
|
|
|
2008-01-31 16:31:39 +00:00
|
|
|
int sd_rindex_uptodate;
|
2006-01-16 16:50:04 +00:00
|
|
|
spinlock_t sd_rindex_spin;
|
GFS2: Use rbtree for resource groups and clean up bitmap buffer ref count scheme
Here is an update of Bob's original rbtree patch which, in addition, also
resolves the rather strange ref counting that was being done relating to
the bitmap blocks.
Originally we had a dual system for journaling resource groups. The metadata
blocks were journaled and also the rgrp itself was added to a list. The reason
for adding the rgrp to the list in the journal was so that the "repolish
clones" code could be run to update the free space, and potentially send any
discard requests when the log was flushed. This was done by comparing the
"cloned" bitmap with what had been written back on disk during the transaction
commit.
Due to this, there was a requirement to hang on to the rgrps' bitmap buffers
until the journal had been flushed. For that reason, there was a rather
complicated set up in the ->go_lock ->go_unlock functions for rgrps involving
both a mutex and a spinlock (the ->sd_rindex_spin) to maintain a reference
count on the buffers.
However, the journal maintains a reference count on the buffers anyway, since
they are being journaled as metadata buffers. So by moving the code which deals
with the post-journal accounting for bitmap blocks to the metadata journaling
code, we can entirely dispense with the rather strange buffer ref counting
scheme and also the requirement to journal the rgrps.
The net result of all this is that the ->sd_rindex_spin is left to do exactly
one job, and that is to look after the rbtree or rgrps.
This patch is designed to be a stepping stone towards using RCU for the rbtree
of resource groups, however the reduction in the number of uses of the
->sd_rindex_spin is likely to have benefits for multi-threaded workloads,
anyway.
The patch retains ->go_lock and ->go_unlock for rgrps, however these maybe also
be removed in future in favour of calling the functions directly where required
in the code. That will allow locking of resource groups without needing to
actually read them in - something that could be useful in speeding up statfs.
In the mean time though it is valid to dereference ->bi_bh only when the rgrp
is locked. This is basically the same rule as before, modulo the references not
being valid until the following journal flush.
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
Signed-off-by: Bob Peterson <rpeterso@redhat.com>
Cc: Benjamin Marzinski <bmarzins@redhat.com>
2011-08-31 08:53:19 +00:00
|
|
|
struct rb_root sd_rindex_tree;
|
2006-01-16 16:50:04 +00:00
|
|
|
unsigned int sd_rgrps;
|
2010-08-20 05:21:02 +00:00
|
|
|
unsigned int sd_max_rg_data;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
/* Journal index stuff */
|
|
|
|
|
|
|
|
struct list_head sd_jindex_list;
|
|
|
|
spinlock_t sd_jindex_spin;
|
2006-02-21 12:51:39 +00:00
|
|
|
struct mutex sd_jindex_mutex;
|
2006-01-16 16:50:04 +00:00
|
|
|
unsigned int sd_journals;
|
|
|
|
|
|
|
|
struct gfs2_jdesc *sd_jdesc;
|
|
|
|
struct gfs2_holder sd_journal_gh;
|
|
|
|
struct gfs2_holder sd_jinode_gh;
|
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-28 19:23:45 +00:00
|
|
|
struct gfs2_glock *sd_jinode_gl;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
struct gfs2_holder sd_sc_gh;
|
2021-06-30 16:46:17 +00:00
|
|
|
struct buffer_head *sd_sc_bh;
|
2006-01-16 16:50:04 +00:00
|
|
|
struct gfs2_holder sd_qc_gh;
|
|
|
|
|
2014-06-02 13:40:25 +00:00
|
|
|
struct completion sd_journal_ready;
|
|
|
|
|
2022-12-06 15:04:22 +00:00
|
|
|
/* Workqueue stuff */
|
|
|
|
|
|
|
|
struct workqueue_struct *sd_delete_wq;
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
/* Daemon stuff */
|
|
|
|
|
|
|
|
struct task_struct *sd_logd_process;
|
|
|
|
struct task_struct *sd_quotad_process;
|
|
|
|
|
|
|
|
/* Quota stuff */
|
|
|
|
|
|
|
|
struct list_head sd_quota_list;
|
|
|
|
atomic_t sd_quota_count;
|
2006-02-21 12:51:39 +00:00
|
|
|
struct mutex sd_quota_mutex;
|
2013-10-04 11:29:34 +00:00
|
|
|
struct mutex sd_quota_sync_mutex;
|
2008-11-17 14:25:37 +00:00
|
|
|
wait_queue_head_t sd_quota_wait;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
unsigned int sd_quota_slots;
|
2013-12-12 17:29:32 +00:00
|
|
|
unsigned long *sd_quota_bitmap;
|
2013-12-13 11:46:28 +00:00
|
|
|
spinlock_t sd_bitmap_lock;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-09-04 16:49:07 +00:00
|
|
|
u64 sd_quota_sync_gen;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
|
|
|
/* Log stuff */
|
|
|
|
|
2013-12-06 16:19:54 +00:00
|
|
|
struct address_space sd_aspace;
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
spinlock_t sd_log_lock;
|
|
|
|
|
GFS2: replace gfs2_ail structure with gfs2_trans
In order to allow transactions and log flushes to happen at the same
time, gfs2 needs to move the transaction accounting and active items
list code into the gfs2_trans structure. As a first step toward this,
this patch removes the gfs2_ail structure, and handles the active items
list in the gfs_trans structure. This keeps gfs2 from allocating an ail
structure on log flushes, and gives us a struture that can later be used
to store the transaction accounting outside of the gfs2 superblock
structure.
With this patch, at the end of a transaction, gfs2 will add the
gfs2_trans structure to the superblock if there is not one already.
This structure now has the active items fields that were previously in
gfs2_ail. This is not necessary in the case where the transaction was
simply used to add revokes, since these are never written outside of the
journal, and thus, don't need an active items list.
Also, in order to make sure that the transaction structure is not
removed while it's still in use by gfs2_trans_end, unlocking the
sd_log_flush_lock has to happen slightly later in ending the
transaction.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2013-04-06 01:31:46 +00:00
|
|
|
struct gfs2_trans *sd_log_tr;
|
2006-01-16 16:50:04 +00:00
|
|
|
unsigned int sd_log_blks_reserved;
|
|
|
|
|
GFS2: Various gfs2_logd improvements
This patch contains various tweaks to how log flushes and active item writeback
work. gfs2_logd is now managed by a waitqueue, and gfs2_log_reseve now waits
for gfs2_logd to do the log flushing. Multiple functions were rewritten to
remove the need to call gfs2_log_lock(). Instead of using one test to see if
gfs2_logd had work to do, there are now seperate tests to check if there
are two many buffers in the incore log or if there are two many items on the
active items list.
This patch is a port of a patch Steve Whitehouse wrote about a year ago, with
some minor changes. Since gfs2_ail1_start always submits all the active items,
it no longer needs to keep track of the first ai submitted, so this has been
removed. In gfs2_log_reserve(), the order of the calls to
prepare_to_wait_exclusive() and wake_up() when firing off the logd thread has
been switched. If it called wake_up first there was a small window for a race,
where logd could run and return before gfs2_log_reserve was ready to get woken
up. If gfs2_logd ran, but did not free up enough blocks, gfs2_log_reserve()
would be left waiting for gfs2_logd to eventualy run because it timed out.
Finally, gt_logd_secs, which controls how long to wait before gfs2_logd times
out, and flushes the log, can now be set on mount with ar_commit.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2010-05-04 19:29:16 +00:00
|
|
|
atomic_t sd_log_pinned;
|
2006-01-16 16:50:04 +00:00
|
|
|
unsigned int sd_log_num_revoke;
|
2006-01-30 18:34:10 +00:00
|
|
|
|
2019-04-05 11:16:14 +00:00
|
|
|
struct list_head sd_log_revokes;
|
|
|
|
struct list_head sd_log_ordered;
|
2013-01-28 09:30:07 +00:00
|
|
|
spinlock_t sd_ordered_lock;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
GFS2: Various gfs2_logd improvements
This patch contains various tweaks to how log flushes and active item writeback
work. gfs2_logd is now managed by a waitqueue, and gfs2_log_reseve now waits
for gfs2_logd to do the log flushing. Multiple functions were rewritten to
remove the need to call gfs2_log_lock(). Instead of using one test to see if
gfs2_logd had work to do, there are now seperate tests to check if there
are two many buffers in the incore log or if there are two many items on the
active items list.
This patch is a port of a patch Steve Whitehouse wrote about a year ago, with
some minor changes. Since gfs2_ail1_start always submits all the active items,
it no longer needs to keep track of the first ai submitted, so this has been
removed. In gfs2_log_reserve(), the order of the calls to
prepare_to_wait_exclusive() and wake_up() when firing off the logd thread has
been switched. If it called wake_up first there was a small window for a race,
where logd could run and return before gfs2_log_reserve was ready to get woken
up. If gfs2_logd ran, but did not free up enough blocks, gfs2_log_reserve()
would be left waiting for gfs2_logd to eventualy run because it timed out.
Finally, gt_logd_secs, which controls how long to wait before gfs2_logd times
out, and flushes the log, can now be set on mount with ar_commit.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2010-05-04 19:29:16 +00:00
|
|
|
atomic_t sd_log_thresh1;
|
|
|
|
atomic_t sd_log_thresh2;
|
2007-11-08 14:55:03 +00:00
|
|
|
atomic_t sd_log_blks_free;
|
2017-01-05 21:01:45 +00:00
|
|
|
atomic_t sd_log_blks_needed;
|
gfs2: Per-revoke accounting in transactions
In the log, revokes are stored as a revoke descriptor (struct
gfs2_log_descriptor), followed by zero or more additional revoke blocks
(struct gfs2_meta_header). On filesystems with a blocksize of 4k, the
revoke descriptor contains up to 503 revokes, and the metadata blocks
contain up to 509 revokes each. We've so far been reserving space for
revokes in transactions in block granularity, so a lot more space than
necessary was being allocated and then released again.
This patch switches to assigning revokes to transactions individually
instead. Initially, space for the revoke descriptor is reserved and
handed out to transactions. When more revokes than that are reserved,
additional revoke blocks are added. When the log is flushed, the space
for the additional revoke blocks is released, but we keep the space for
the revoke descriptor block allocated.
Transactions may still reserve more revokes than they will actually need
in the end, but now we won't overshoot the target as much, and by only
returning the space for excess revokes at log flush time, we further
reduce the amount of contention between processes.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
2020-12-17 15:14:30 +00:00
|
|
|
atomic_t sd_log_revokes_available;
|
GFS2: Various gfs2_logd improvements
This patch contains various tweaks to how log flushes and active item writeback
work. gfs2_logd is now managed by a waitqueue, and gfs2_log_reseve now waits
for gfs2_logd to do the log flushing. Multiple functions were rewritten to
remove the need to call gfs2_log_lock(). Instead of using one test to see if
gfs2_logd had work to do, there are now seperate tests to check if there
are two many buffers in the incore log or if there are two many items on the
active items list.
This patch is a port of a patch Steve Whitehouse wrote about a year ago, with
some minor changes. Since gfs2_ail1_start always submits all the active items,
it no longer needs to keep track of the first ai submitted, so this has been
removed. In gfs2_log_reserve(), the order of the calls to
prepare_to_wait_exclusive() and wake_up() when firing off the logd thread has
been switched. If it called wake_up first there was a small window for a race,
where logd could run and return before gfs2_log_reserve was ready to get woken
up. If gfs2_logd ran, but did not free up enough blocks, gfs2_log_reserve()
would be left waiting for gfs2_logd to eventualy run because it timed out.
Finally, gt_logd_secs, which controls how long to wait before gfs2_logd times
out, and flushes the log, can now be set on mount with ar_commit.
Signed-off-by: Benjamin Marzinski <bmarzins@redhat.com>
Signed-off-by: Steven Whitehouse <swhiteho@redhat.com>
2010-05-04 19:29:16 +00:00
|
|
|
wait_queue_head_t sd_log_waitq;
|
|
|
|
wait_queue_head_t sd_logd_waitq;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2006-09-04 16:49:07 +00:00
|
|
|
u64 sd_log_sequence;
|
2006-01-16 16:50:04 +00:00
|
|
|
int sd_log_idle;
|
|
|
|
|
2006-03-29 14:12:12 +00:00
|
|
|
struct rw_semaphore sd_log_flush_lock;
|
2007-09-17 09:59:52 +00:00
|
|
|
atomic_t sd_log_in_flight;
|
|
|
|
wait_queue_head_t sd_log_flush_wait;
|
2019-04-10 17:46:35 +00:00
|
|
|
int sd_log_error; /* First log 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-28 19:23:45 +00:00
|
|
|
wait_queue_head_t sd_withdraw_wait;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2020-12-19 06:15:17 +00:00
|
|
|
unsigned int sd_log_tail;
|
|
|
|
unsigned int sd_log_flush_tail;
|
|
|
|
unsigned int sd_log_head;
|
2006-01-16 16:50:04 +00:00
|
|
|
unsigned int sd_log_flush_head;
|
|
|
|
|
2011-03-11 11:52:25 +00:00
|
|
|
spinlock_t sd_ail_lock;
|
2006-01-16 16:50:04 +00:00
|
|
|
struct list_head sd_ail1_list;
|
|
|
|
struct list_head sd_ail2_list;
|
|
|
|
|
|
|
|
/* For quiescing the filesystem */
|
|
|
|
struct gfs2_holder sd_freeze_gh;
|
2014-11-14 02:42:04 +00:00
|
|
|
struct mutex sd_freeze_mutex;
|
2006-01-16 16:50:04 +00:00
|
|
|
|
2017-08-22 17:17:35 +00:00
|
|
|
char sd_fsname[GFS2_FSNAME_LEN + 3 * sizeof(int) + 2];
|
2006-01-16 16:50:04 +00:00
|
|
|
char sd_table_name[GFS2_FSNAME_LEN];
|
|
|
|
char sd_proto_name[GFS2_FSNAME_LEN];
|
|
|
|
|
|
|
|
/* Debugging crud */
|
|
|
|
|
|
|
|
unsigned long sd_last_warning;
|
2007-04-18 16:41:11 +00:00
|
|
|
struct dentry *debugfs_dir; /* debugfs directory */
|
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-28 19:23:45 +00:00
|
|
|
unsigned long sd_glock_dqs_held;
|
2006-01-16 16:50:04 +00: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 10:38:36 +00:00
|
|
|
static inline void gfs2_glstats_inc(struct gfs2_glock *gl, int which)
|
|
|
|
{
|
|
|
|
gl->gl_stats.stats[which]++;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline void gfs2_sbstats_inc(const struct gfs2_glock *gl, int which)
|
|
|
|
{
|
2015-03-16 16:52:05 +00:00
|
|
|
const struct gfs2_sbd *sdp = gl->gl_name.ln_sbd;
|
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 10:38:36 +00:00
|
|
|
preempt_disable();
|
|
|
|
this_cpu_ptr(sdp->sd_lkstats)->lkstats[gl->gl_name.ln_type].stats[which]++;
|
|
|
|
preempt_enable();
|
|
|
|
}
|
|
|
|
|
2017-06-30 12:55:08 +00:00
|
|
|
extern struct gfs2_rgrpd *gfs2_glock2rgrp(struct gfs2_glock *gl);
|
|
|
|
|
2017-11-14 15:53:12 +00:00
|
|
|
static inline unsigned gfs2_max_stuffed_size(const struct gfs2_inode *ip)
|
|
|
|
{
|
|
|
|
return GFS2_SB(&ip->i_inode)->sd_sb.sb_bsize - sizeof(struct gfs2_dinode);
|
|
|
|
}
|
|
|
|
|
2006-01-16 16:50:04 +00:00
|
|
|
#endif /* __INCORE_DOT_H__ */
|
|
|
|
|