<feed xmlns='http://www.w3.org/2005/Atom'>
<title>wireguard-linux/fs/gfs2/util.c, branch jd/unified-crypt-queue</title>
<subtitle>WireGuard for the Linux kernel</subtitle>
<id>https://git.zx2c4.com/wireguard-linux/atom/fs/gfs2/util.c?h=jd%2Funified-crypt-queue</id>
<link rel='self' href='https://git.zx2c4.com/wireguard-linux/atom/fs/gfs2/util.c?h=jd%2Funified-crypt-queue'/>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/'/>
<updated>2020-02-27T13:53:18Z</updated>
<entry>
<title>gfs2: flesh out delayed withdraw for gfs2_log_flush</title>
<updated>2020-02-27T13:53:18Z</updated>
<author>
<name>Bob Peterson</name>
<email>rpeterso@redhat.com</email>
</author>
<published>2020-01-08T17:37:30Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=ca399c96e96e3f372f901a698a6fd17796b8ed32'/>
<id>urn:sha1:ca399c96e96e3f372f901a698a6fd17796b8ed32</id>
<content type='text'>
Function gfs2_log_flush() had a few places where it tried to withdraw
from the file system when errors were encountered. The problem is,
it should delay those withdraws until the log flush lock is no longer
held.

This patch creates a new function just for delayed withdraws for
situations like this. If errors=panic was specified on mount, we
still want to do it the old fashioned way because the panic it does
not help to delay in that situation.

Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
Reviewed-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Add verbose option to check_journal_clean</title>
<updated>2020-02-27T13:53:17Z</updated>
<author>
<name>Bob Peterson</name>
<email>rpeterso@redhat.com</email>
</author>
<published>2019-02-18T20:04:13Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=7d9f9249580e05a9af823cdbb7a91f2758d1c63b'/>
<id>urn:sha1:7d9f9249580e05a9af823cdbb7a91f2758d1c63b</id>
<content type='text'>
Before this patch, function check_journal_clean would give messages
related to journal recovery. That's fine for mount time, but when a
node withdraws and forces replay that way, we don't want all those
distracting and misleading messages. This patch adds a new parameter
to make those messages optional.

Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
Reviewed-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Force withdraw to replay journals and wait for it to finish</title>
<updated>2020-02-27T13:53:12Z</updated>
<author>
<name>Bob Peterson</name>
<email>rpeterso@redhat.com</email>
</author>
<published>2020-01-28T19:23:45Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=601ef0d52e9617588fcff3df26953592f2eb44ac'/>
<id>urn:sha1:601ef0d52e9617588fcff3df26953592f2eb44ac</id>
<content type='text'>
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 &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: move check_journal_clean to util.c for future use</title>
<updated>2020-02-10T13:39:51Z</updated>
<author>
<name>Bob Peterson</name>
<email>rpeterso@redhat.com</email>
</author>
<published>2019-02-18T15:37:25Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=0d91061a372671aec1af729686ad9241a59fc328'/>
<id>urn:sha1:0d91061a372671aec1af729686ad9241a59fc328</id>
<content type='text'>
Before this patch function check_journal_clean was in ops_fstype.c.
This patch moves it to util.c so we can make use of it elsewhere
in a future patch.

Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
Reviewed-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Introduce concept of a pending withdraw</title>
<updated>2020-02-10T13:39:47Z</updated>
<author>
<name>Bob Peterson</name>
<email>rpeterso@redhat.com</email>
</author>
<published>2019-02-12T20:43:55Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=69511080bd6efd34f4e020fcde6cf73bb4a61af6'/>
<id>urn:sha1:69511080bd6efd34f4e020fcde6cf73bb4a61af6</id>
<content type='text'>
File system withdraws can be delayed when inconsistencies are
discovered when we cannot withdraw immediately, for example, when
critical spin_locks are held. But delaying the withdraw can cause
gfs2 to ignore the error and keep running for a short period of time.
For example, an rgrp glock may be dequeued and demoted while there
are still buffers that haven't been properly revoked, due to io
errors writing to the journal.

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

Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
Reviewed-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Return bool from gfs2_assert functions</title>
<updated>2020-02-10T13:39:47Z</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2020-01-23T18:36:21Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=8e28ef1f2fa176854f96fb0416f2aaf5516793d0'/>
<id>urn:sha1:8e28ef1f2fa176854f96fb0416f2aaf5516793d0</id>
<content type='text'>
The gfs2_assert functions only print messages when the filesystem hasn't been
withdrawn yet, and they indicate whether or not they've printed something in
their return value.  However, none of the callers use that information, so
simply return whether or not the assert has failed.

(The gfs2_assert functions are still backwards; they return false when an
assertion is true.)

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Turn gfs2_consist into void functions</title>
<updated>2020-02-10T13:39:46Z</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2020-01-23T18:31:06Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=a5ca2f1cb66b1ef93bbd58b55b22cb50163a03db'/>
<id>urn:sha1:a5ca2f1cb66b1ef93bbd58b55b22cb50163a03db</id>
<content type='text'>
Change the various gfs2_consist functions to return void.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Remove usused cluster_wide arguments of gfs2_consist functions</title>
<updated>2020-02-10T13:39:45Z</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2020-01-23T18:25:05Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=d7e7ab3f1e2283ef956bb94fee09e80dbc1c46e9'/>
<id>urn:sha1:d7e7ab3f1e2283ef956bb94fee09e80dbc1c46e9</id>
<content type='text'>
These arguments are always passed as 0, and they are never evaluated.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Split gfs2_lm_withdraw into two functions</title>
<updated>2020-02-10T13:39:44Z</updated>
<author>
<name>Andreas Gruenbacher</name>
<email>agruenba@redhat.com</email>
</author>
<published>2020-01-23T17:41:00Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=badb55ec208adc4c406ed084f486deb1f9f5baa0'/>
<id>urn:sha1:badb55ec208adc4c406ed084f486deb1f9f5baa0</id>
<content type='text'>
Split gfs2_lm_withdraw into a function that prints an error message and a
function that withdraws the filesystem.

Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
</content>
</entry>
<entry>
<title>gfs2: Introduce function gfs2_withdrawn</title>
<updated>2019-11-14T18:46:18Z</updated>
<author>
<name>Bob Peterson</name>
<email>rpeterso@redhat.com</email>
</author>
<published>2019-11-14T14:52:15Z</published>
<link rel='alternate' type='text/html' href='https://git.zx2c4.com/wireguard-linux/commit/?id=eb43e660c094029fc1165e2641ce06c153129bdd'/>
<id>urn:sha1:eb43e660c094029fc1165e2641ce06c153129bdd</id>
<content type='text'>
Add function gfs2_withdrawn and replace all checks for the SDF_WITHDRAWN
bit to call it. This does not change the logic or function of gfs2, and
it facilitates later improvements to the withdraw sequence.

Signed-off-by: Bob Peterson &lt;rpeterso@redhat.com&gt;
Signed-off-by: Andreas Gruenbacher &lt;agruenba@redhat.com&gt;
</content>
</entry>
</feed>
