From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: darrick.wong@oracle.com
Cc: linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org,
linux-api@vger.kernel.org
Subject: [PATCH 07/18] xfs: allow deferred ops items to put themselves at the end of the pending queue
Date: Tue, 28 Apr 2020 19:45:00 -0700 [thread overview]
Message-ID: <158812830045.168506.2200063100219298803.stgit@magnolia> (raw)
In-Reply-To: <158812825316.168506.932540609191384366.stgit@magnolia>
From: Darrick J. Wong <darrick.wong@oracle.com>
Allow individual deferred op ->finish_item functions to decide that they
want to yield to all other deferred ops that might need processing.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
---
fs/xfs/libxfs/xfs_defer.c | 29 +++++++++++++++++++++++------
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/fs/xfs/libxfs/xfs_defer.c b/fs/xfs/libxfs/xfs_defer.c
index 1cab95cef399..f53e3ce858eb 100644
--- a/fs/xfs/libxfs/xfs_defer.c
+++ b/fs/xfs/libxfs/xfs_defer.c
@@ -69,10 +69,10 @@
* - For each work item attached to the log intent item,
* * Perform the described action.
* * Attach the work item to the log done item.
- * * If the result of doing the work was -EAGAIN, ->finish work
- * wants a new transaction. See the "Requesting a Fresh
- * Transaction while Finishing Deferred Work" section below for
- * details.
+ * * If the result of doing the work was -EAGAIN or -EMULTIHOP,
+ * ->finish work wants a new transaction. See the "Requesting a
+ * Fresh Transaction while Finishing Deferred Work" section below
+ * for details.
*
* The key here is that we must log an intent item for all pending
* work items every time we roll the transaction, and that we must log
@@ -108,6 +108,13 @@
* required that ->finish_item must be careful to leave enough
* transaction reservation to fit the new log intent item.
*
+ * If ->finish_item returns -EMULTIHOP, defer_finish will log the new
+ * intent item with the remaining work items but it will move the
+ * xfs_defer_pending item to a separate queue. The separate queue
+ * will be put back into the pending list at the very end of processing
+ * after all other pending items (including ones that were created as
+ * part of finishing other items) have been processed.
+ *
* This is an example of remapping the extent (E, E+B) into file X at
* offset A and dealing with the extent (C, C+B) already being mapped
* there:
@@ -365,12 +372,14 @@ xfs_defer_finish_noroll(
int error = 0;
const struct xfs_defer_op_type *ops;
LIST_HEAD(dop_pending);
+ LIST_HEAD(dop_endofline);
ASSERT((*tp)->t_flags & XFS_TRANS_PERM_LOG_RES);
trace_xfs_defer_finish(*tp, _RET_IP_);
/* Until we run out of pending work to finish... */
+again:
while (!list_empty(&dop_pending) || !list_empty(&(*tp)->t_dfops)) {
/* log intents and pull in intake items */
xfs_defer_create_intents(*tp);
@@ -398,7 +407,7 @@ xfs_defer_finish_noroll(
dfp->dfp_count--;
error = ops->finish_item(*tp, li, dfp->dfp_done,
&state);
- if (error == -EAGAIN) {
+ if (error == -EAGAIN || error == -EMULTIHOP) {
/*
* Caller wants a fresh transaction;
* put the work item back on the list
@@ -418,7 +427,7 @@ xfs_defer_finish_noroll(
goto out;
}
}
- if (error == -EAGAIN) {
+ if (error == -EAGAIN || error == -EMULTIHOP) {
/*
* Caller wants a fresh transaction, so log a
* new log intent item to replace the old one
@@ -431,6 +440,8 @@ xfs_defer_finish_noroll(
dfp->dfp_done = NULL;
list_for_each(li, &dfp->dfp_work)
ops->log_item(*tp, dfp->dfp_intent, li);
+ if (error == -EMULTIHOP)
+ list_move_tail(&dfp->dfp_list, &dop_endofline);
} else {
/* Done with the dfp, free it. */
list_del(&dfp->dfp_list);
@@ -441,8 +452,14 @@ xfs_defer_finish_noroll(
ops->finish_cleanup(*tp, state, error);
}
+ if (!list_empty(&dop_endofline)) {
+ list_splice_tail_init(&dop_endofline, &dop_pending);
+ goto again;
+ }
+
out:
if (error) {
+ list_splice_tail_init(&dop_endofline, &dop_pending);
xfs_defer_trans_abort(*tp, &dop_pending);
xfs_force_shutdown((*tp)->t_mountp, SHUTDOWN_CORRUPT_INCORE);
trace_xfs_defer_finish_error(*tp, error);
next prev parent reply other threads:[~2020-04-29 2:45 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 2:44 [PATCH RFC 00/18] xfs: atomic file updates Darrick J. Wong
2020-04-29 2:44 ` [PATCH 01/18] xfs: clean up the error handling in xfs_swap_extent_rmap Darrick J. Wong
2020-04-29 2:44 ` [PATCH 02/18] xfs: fix xfs_reflink_remap_prep calling conventions Darrick J. Wong
2020-05-01 22:54 ` Allison Collins
2020-04-29 2:44 ` [PATCH 03/18] vfs: introduce new file extent swap ioctl Darrick J. Wong
2020-04-29 2:44 ` [PATCH 04/18] xfs: support deferred bmap updates on the attr fork Darrick J. Wong
2020-04-29 2:44 ` [PATCH 05/18] xfs: xfs_bmap_finish_one should map unwritten extents properly Darrick J. Wong
2020-04-29 2:44 ` [PATCH 06/18] xfs: create a log incompat flag for atomic extent swapping Darrick J. Wong
2020-04-29 2:45 ` Darrick J. Wong [this message]
2020-04-29 2:45 ` [PATCH 08/18] xfs: introduce a swap-extent log intent item Darrick J. Wong
2020-04-29 2:45 ` [PATCH 09/18] xfs: create deferred log items for extent swapping Darrick J. Wong
2020-04-29 2:45 ` [PATCH 10/18] xfs: refactor locking and unlocking two inodes against userspace IO Darrick J. Wong
2020-04-29 2:45 ` [PATCH 11/18] xfs: add a ->swap_file_range handler Darrick J. Wong
2020-04-29 2:45 ` [PATCH 12/18] xfs: add error injection to test swapext recovery Darrick J. Wong
2020-04-29 2:45 ` [PATCH 13/18] xfs: allow xfs_swap_range to use older extent swap algorithms Darrick J. Wong
2020-04-29 2:45 ` [PATCH 14/18] xfs: port xfs_swap_extents_rmap to our new code Darrick J. Wong
2020-04-29 2:45 ` [PATCH 15/18] xfs: consolidate all of the xfs_swap_extent_forks code Darrick J. Wong
2020-04-29 2:45 ` [PATCH 16/18] xfs: refactor reflink flag handling in xfs_swap_extent_forks Darrick J. Wong
2020-04-29 2:46 ` [PATCH 17/18] xfs: remove old swap extents implementation Darrick J. Wong
2020-04-29 2:46 ` [PATCH 18/18] xfs: fix quota accounting in the old fork swap code Darrick J. Wong
2020-05-01 19:46 ` [PATCH RFC 00/18] xfs: atomic file updates Jann Horn
2020-05-01 20:11 ` 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=158812830045.168506.2200063100219298803.stgit@magnolia \
--to=darrick.wong@oracle.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-xfs@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