Bob,
On Wed, 1 May 2019 at 01:03, Bob Peterson wrote:
> File system withdraws can be delayed when inconsistencies are
> discovered when we cannot withdraw immediately, for example, when
> critical spin_locks are held. But delaying the withdraw can cause
> gfs2 to ignore the error and keep
Hi Linus,
Here are some patches for the iomap code for 5.2. Nothing particularly
exciting here, just adding some callouts for gfs2 and cleaning a few
things. It merges cleanly against this morning's HEAD and survived an
overnight run of xfstests. Let me know if you run into anything weird.
Bob,
On Wed, 1 May 2019 at 01:03, Bob Peterson wrote:
> This patch adds some instrumentation in gfs2's journal replay that
> indicates when we're about to overwrite a rgrp for which we already
> have a valid buffer_head.
looks okay, but can you explain in the commit message when this
problem
Support for automatic failover in the face of network interruptions
is being added to the DLM kernel component. [1] This patch aids in that
effort by adding a mechanism whereby userspace can convey to the
kernel its intention to use all network addresses for automatic
failover. DLM's current
From: Bob Peterson
The gl_revokes value determines how many outstanding revokes a glock has
on the superblock revokes list; this is used to avoid unnecessary log
flushes. However, gl_revokes is only ever tested for being zero, and it's
only decremented in revoke_lo_after_commit, which removes
This patch has to do with the life cycle of glocks and buffers. When
gfs2 metadata or journaled data is queued to be written, a gfs2_bufdata
object is assigned to track the buffer, and that is queued to various
lists, including the glock's gl_ail_list to indicate it's on the active
items list.
From: Ross Lagerwall
Under certain conditions, lru_count may drop below zero resulting in
a large amount of log spam like this:
vmscan: shrink_slab: gfs2_dump_glock+0x3b0/0x630 [gfs2] \
negative objects to delete nr=-1
This happens as follows:
1) A glock is moved from lru_list to the
Make log operations statuc; they are only used locally.
Signed-off-by: Andreas Gruenbacher
---
fs/gfs2/lops.c | 6 +++---
fs/gfs2/lops.h | 5 -
2 files changed, 3 insertions(+), 8 deletions(-)
diff --git a/fs/gfs2/lops.c b/fs/gfs2/lops.c
index 2fd61853ba63..6c1ec6c60639 100644
---
From: Abhi Das
As part of the freeze operation, gfs2_freeze_func() is left blocking
on a request to hold the sd_freeze_gl in SH. This glock is held in EX
by the gfs2_freeze() code.
A subsequent call to gfs2_unfreeze() releases the EXclusively held
sd_freeze_gl, which allows gfs2_freeze_func()
Since commit 64bc06bb32ee ("gfs2: iomap buffered write support"), gfs2 is doing
buffered writes by starting a transaction in iomap_begin, writing a range of
pages, and ending that transaction in iomap_end. This approach suffers from
two problems:
(1) Any allocations necessary for the write are
Fix the resource group wrap-around logic in gfs2_rbm_find that commit
e579ed4f44 broke. The bug can lead to unnecessary repeated scanning of the
same bitmaps; there is a risk that future changes will turn this into an
endless loop.
This is an updated version of commit 2d29f6b96d ("gfs2: Fix loop
Signed-off-by: Andreas Gruenbacher
---
fs/gfs2/super.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/gfs2/super.c b/fs/gfs2/super.c
index e20fa55715e2..a6a325b2a78b 100644
--- a/fs/gfs2/super.c
+++ b/fs/gfs2/super.c
@@ -1630,8 +1630,6 @@ static void gfs2_evict_inode(struct inode
From: Bob Peterson
This patch fixes regressions in 588bff95c94efc05f9e1a0b19015c9408ed7c0ef.
Due to that patch, function clean_journal was setting the value of
sd_log_flush_head, but that's only valid if it is replaying the node's
own journal. If it's replaying another node's journal, that's
Rename sd_log_le_revoke to sd_log_revokes and sd_log_le_ordered to
sd_log_ordered: not sure what le stands for here, but it doesn't add
clarity, and if it stands for list entry, it's actually confusing as
those are both list heads but not list entries.
Signed-off-by: Andreas Gruenbacher
---
From: Abhi Das
Use bios to read in the journal into the address space of the journal inode
(jd_inode), sequentially and in large chunks. This is faster for locating the
journal head that the previous binary search approach. When performing
recovery, we keep the journal in the address space
Hello,
for this merge window, we've got the following patches:
"gfs2: Fix loop in gfs2_rbm_find (v2)"
A rework of a fix we ended up reverting in the 5.0 kernel because of
an iozone performance regression.
"gfs2: read journal in large chunks" and
"gfs2: fix race between gfs2_freeze_func and
16 matches
Mail list logo
