From: Sasha Levin <sashal@kernel.org>
To: linux-kernel@vger.kernel.org, stable@vger.kernel.org
Cc: Brian Foster <bfoster@redhat.com>,
"Darrick J . Wong" <darrick.wong@oracle.com>,
Christoph Hellwig <hch@lst.de>,
Allison Collins <allison.henderson@oracle.com>,
Sasha Levin <sashal@kernel.org>,
linux-xfs@vger.kernel.org
Subject: [PATCH AUTOSEL 5.7 173/274] xfs: reset buffer write failure state on successful completion
Date: Mon, 8 Jun 2020 19:04:26 -0400 [thread overview]
Message-ID: <20200608230607.3361041-173-sashal@kernel.org> (raw)
In-Reply-To: <20200608230607.3361041-1-sashal@kernel.org>
From: Brian Foster <bfoster@redhat.com>
[ Upstream commit b6983e80b03bd4fd42de71993b3ac7403edac758 ]
The buffer write failure flag is intended to control the internal
write retry that XFS has historically implemented to help mitigate
the severity of transient I/O errors. The flag is set when a buffer
is resubmitted from the I/O completion path due to a previous
failure. It is checked on subsequent I/O completions to skip the
internal retry and fall through to the higher level configurable
error handling mechanism. The flag is cleared in the synchronous and
delwri submission paths and also checked in various places to log
write failure messages.
There are a couple minor problems with the current usage of this
flag. One is that we issue an internal retry after every submission
from xfsaild due to how delwri submission clears the flag. This
results in double the expected or configured number of write
attempts when under sustained failures. Another more subtle issue is
that the flag is never cleared on successful I/O completion. This
can cause xfs_wait_buftarg() to suggest that dirty buffers are being
thrown away due to the existence of the flag, when the reality is
that the flag might still be set because the write succeeded on the
retry.
Clear the write failure flag on successful I/O completion to address
both of these problems. This means that the internal retry attempt
occurs once since the last time a buffer write failed and that
various other contexts only see the flag set when the immediately
previous write attempt has failed.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Allison Collins <allison.henderson@oracle.com>
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
fs/xfs/xfs_buf.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/fs/xfs/xfs_buf.c b/fs/xfs/xfs_buf.c
index 9ec3eaf1c618..afa73a19caa1 100644
--- a/fs/xfs/xfs_buf.c
+++ b/fs/xfs/xfs_buf.c
@@ -1197,8 +1197,10 @@ xfs_buf_ioend(
bp->b_ops->verify_read(bp);
}
- if (!bp->b_error)
+ if (!bp->b_error) {
+ bp->b_flags &= ~XBF_WRITE_FAIL;
bp->b_flags |= XBF_DONE;
+ }
if (bp->b_iodone)
(*(bp->b_iodone))(bp);
@@ -1258,7 +1260,7 @@ xfs_bwrite(
bp->b_flags |= XBF_WRITE;
bp->b_flags &= ~(XBF_ASYNC | XBF_READ | _XBF_DELWRI_Q |
- XBF_WRITE_FAIL | XBF_DONE);
+ XBF_DONE);
error = xfs_buf_submit(bp);
if (error)
@@ -1983,7 +1985,7 @@ xfs_buf_delwri_submit_buffers(
* synchronously. Otherwise, drop the buffer from the delwri
* queue and submit async.
*/
- bp->b_flags &= ~(_XBF_DELWRI_Q | XBF_WRITE_FAIL);
+ bp->b_flags &= ~_XBF_DELWRI_Q;
bp->b_flags |= XBF_WRITE;
if (wait_list) {
bp->b_flags &= ~XBF_ASYNC;
--
2.25.1
next prev parent reply other threads:[~2020-06-09 0:52 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200608230607.3361041-1-sashal@kernel.org>
2020-06-08 23:02 ` [PATCH AUTOSEL 5.7 072/274] xfs: more lockdep whackamole with kmem_alloc* Sasha Levin
2020-06-08 23:04 ` [PATCH AUTOSEL 5.7 165/274] xfs: clean up the error handling in xfs_swap_extents Sasha Levin
2020-06-08 23:04 ` Sasha Levin [this message]
2020-06-08 23:04 ` [PATCH AUTOSEL 5.7 174/274] xfs: fix duplicate verification from xfs_qm_dqflush() Sasha Levin
2020-06-08 23:05 ` [PATCH AUTOSEL 5.7 214/274] xfs: don't fail verifier on empty attr3 leaf block Sasha Levin
2020-06-08 23:05 ` [PATCH AUTOSEL 5.7 242/274] xfs: gut error handling in xfs_trans_unreserve_and_mod_sb() Sasha Levin
2020-06-08 23:05 ` [PATCH AUTOSEL 5.7 243/274] xfs: measure all contiguous previous extents for prealloc size Sasha Levin
2020-06-08 23:05 ` [PATCH AUTOSEL 5.7 244/274] xfs: force writes to delalloc regions to unwritten Sasha Levin
2020-06-09 1:07 ` Darrick J. Wong
2020-06-09 2:10 ` Sasha Levin
2020-06-09 4:27 ` Darrick J. Wong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200608230607.3361041-173-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=allison.henderson@oracle.com \
--cc=bfoster@redhat.com \
--cc=darrick.wong@oracle.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-xfs@vger.kernel.org \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox