public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Wengang Wang <wen.gang.wang@oracle.com>
To: linux-xfs@vger.kernel.org
Cc: wen.gang.wang@oracle.com
Subject: [PATCH 1/2] xfs: IO time one extent per EFI
Date: Fri, 14 Apr 2023 15:58:35 -0700	[thread overview]
Message-ID: <20230414225836.8952-2-wen.gang.wang@oracle.com> (raw)
In-Reply-To: <20230414225836.8952-1-wen.gang.wang@oracle.com>

At IO time, make sure an EFI contains only one extent. Transaction rolling in
xfs_defer_finish() would commit the busy blocks for previous EFIs. By that we
avoid holding busy extents (for previously extents in the same EFI) in current
transaction when allocating blocks for AGFL where we could be otherwise stuck
waiting the busy extents held by current transaction to be flushed (thus a
deadlock).

The log changes
1) before change:

    358 rbbn 13 rec_lsn: 1,12 Oper 5: tid: ee327fd2  len: 48 flags: None
    359 EFI  nextents:2 id:ffff9fef708ba940
    360 EFI id=ffff9fef708ba940 (0x21, 7)
    361 EFI id=ffff9fef708ba940 (0x18, 8)
    362 -----------------------------------------------------------------
    363 rbbn 13 rec_lsn: 1,12 Oper 6: tid: ee327fd2  len: 48 flags: None
    364 EFD  nextents:2 id:ffff9fef708ba940
    365 EFD id=ffff9fef708ba940 (0x21, 7)
    366 EFD id=ffff9fef708ba940 (0x18, 8)

2) after change:

    830 rbbn 31 rec_lsn: 1,30 Oper 5: tid: 319f015f  len: 32 flags: None
    831 EFI  nextents:1 id:ffff9fef708b9b80
    832 EFI id=ffff9fef708b9b80 (0x21, 7)
    833 -----------------------------------------------------------------
    834 rbbn 31 rec_lsn: 1,30 Oper 6: tid: 319f015f  len: 32 flags: None
    835 EFI  nextents:1 id:ffff9fef708b9d38
    836 EFI id=ffff9fef708b9d38 (0x18, 8)
    837 -----------------------------------------------------------------
    838 rbbn 31 rec_lsn: 1,30 Oper 7: tid: 319f015f  len: 32 flags: None
    839 EFD  nextents:1 id:ffff9fef708b9b80
    840 EFD id=ffff9fef708b9b80 (0x21, 7)
    841 -----------------------------------------------------------------
    842 rbbn 31 rec_lsn: 1,30 Oper 8: tid: 319f015f  len: 32 flags: None
    843 EFD  nextents:1 id:ffff9fef708b9d38
    844 EFD id=ffff9fef708b9d38 (0x18, 8)

Signed-off-by: Wengang Wang <wen.gang.wang@oracle.com>
---
 fs/xfs/xfs_extfree_item.h | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/fs/xfs/xfs_extfree_item.h b/fs/xfs/xfs_extfree_item.h
index da6a5afa607c..ae84d77eaf30 100644
--- a/fs/xfs/xfs_extfree_item.h
+++ b/fs/xfs/xfs_extfree_item.h
@@ -13,8 +13,15 @@ struct kmem_cache;
 
 /*
  * Max number of extents in fast allocation path.
+ *
+ * At IO time, make sure an EFI contains only one extent. Transaction rolling
+ * in xfs_defer_finish() would commit the busy blocks for previous EFIs. By
+ * that we avoid holding busy extents (for previously extents in the same EFI)
+ * in current transaction when allocating blocks for AGFL where we could be
+ * otherwise stuck waiting the busy extents held by current transaction to be
+ * flushed (thus a deadlock).
  */
-#define	XFS_EFI_MAX_FAST_EXTENTS	16
+#define	XFS_EFI_MAX_FAST_EXTENTS	1
 
 /*
  * This is the "extent free intention" log item.  It is used to log the fact
-- 
2.21.0 (Apple Git-122.2)


  reply	other threads:[~2023-04-14 22:58 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-14 22:58 [PATCH 0/2] xfs: one extent per EFI Wengang Wang
2023-04-14 22:58 ` Wengang Wang [this message]
2023-04-19 23:55   ` [PATCH 1/2] xfs: IO time " Dave Chinner
2023-04-20 17:31     ` Wengang Wang
2023-04-20 23:22       ` Dave Chinner
2023-04-21  0:24         ` Wengang Wang
2023-04-21  9:34           ` Dave Chinner
2023-04-21 18:23             ` Wengang Wang
2023-04-22  3:22               ` Wengang Wang
2023-04-24 15:53                 ` Wengang Wang
2023-04-24 22:52                   ` Wengang Wang
2023-04-14 22:58 ` [PATCH 2/2] xfs: log recovery stage split EFIs with multiple extents Wengang Wang
2023-04-20  0:30   ` Dave Chinner
2023-04-20 17:10     ` Wengang Wang
2023-04-20 22:54       ` Dave Chinner
2023-04-21  0:32         ` Wengang Wang

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=20230414225836.8952-2-wen.gang.wang@oracle.com \
    --to=wen.gang.wang@oracle.com \
    --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