From patchwork Thu Jul 20 20:12:14 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 13321024 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4391BEB64DD for ; Thu, 20 Jul 2023 20:12:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229750AbjGTUM3 (ORCPT ); Thu, 20 Jul 2023 16:12:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57638 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229519AbjGTUM0 (ORCPT ); Thu, 20 Jul 2023 16:12:26 -0400 Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CB5E32706 for ; Thu, 20 Jul 2023 13:12:24 -0700 (PDT) Received: by mail-qt1-x832.google.com with SMTP id d75a77b69052e-403a0d7afafso9175271cf.1 for ; Thu, 20 Jul 2023 13:12:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20221208.gappssmtp.com; s=20221208; t=1689883944; x=1690488744; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=Xn3BA+RG7or9vpEE8yBA/c0E6nv8+kjWIrDLe08avnY=; b=IkoGaOSA5KPEb4aWm43LBrRPLT9t9aZh0kmAfdMWVplG7rgUrMBtBfiCeBRJ1LGYwM q+I3DQxU6mtd5LpLFaOURsb3sUQGWJPUERE0g8EFYT4Itbzxl6Y2H7OV/S3ZZ/pqUdRo 2qIONrpejZuSanIgHanxXKdReidXJ19wMDt/IHnt/m7+1dhYlDpjXcz+8gpI1a5EAVH4 SnfiPdBHmNDK1yTzzZUsulJL2PlwveFAO74gTSLL/wBuU71fJGI60hI/q2vHbQiiwyeR YJ2dx37AOY7tzlt1W3OeUYgeHcLK9zRmmEzMwWXOdLdWNVFUOFXz4x5aL/6FzhLDq6y+ qIkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689883944; x=1690488744; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Xn3BA+RG7or9vpEE8yBA/c0E6nv8+kjWIrDLe08avnY=; b=f5Qcfn8rgEINMYnN3cvKybLgr2Oum6gg7j4gbjv/sg6uvUxC8LwLU3wh1cEraFBVM5 oh+IJ0krdK5wnzcIsXxaXrMiXT48fkq7pmTLVluLEr1xG1khQZrjvVbGwDYEyY3tzMst 0xaxy6RymZ1o6QopLnDdypd8Q/P0vB8BdxcMe7wnVGpyAym0pNj7BwtWrVNXn8982Jrf ynMlnklQty1tnVAWznVEsfJ3xIkAt4LerLot4E75z755/1nGcOm+pDXyENnfFUr/bIZO c1YRBi/FtQDGQjy10VlhOci4sBm3ct3RG6v5uCxaLpErRRwy0mLeByH6u8pMgCLgX56j kCaA== X-Gm-Message-State: ABy/qLZVtLqsJI55HYrb1zqQQsMU7T/sGyDxj9TC5vAS8v8zs66qpTgU OQ8ELy11bRI/2YDHw17JRYJtcZT/8CTWwfJnGM/oVQ== X-Google-Smtp-Source: APBJJlHuU+7a6AqY8LyeNOtLS4YHf+vZAChO16hpNTJXAoKhjJE9f2QPBmpzn1N7ssQ6+p9C6Swj4g== X-Received: by 2002:ac8:580a:0:b0:403:b4da:6f65 with SMTP id g10-20020ac8580a000000b00403b4da6f65mr148764qtg.39.1689883943455; Thu, 20 Jul 2023 13:12:23 -0700 (PDT) Received: from localhost (cpe-76-182-20-124.nc.res.rr.com. [76.182.20.124]) by smtp.gmail.com with ESMTPSA id j6-20020ac86646000000b004032d9209a0sm677093qtp.50.2023.07.20.13.12.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jul 2023 13:12:23 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 1/3] btrfs: wait for block groups to finish caching during allocation Date: Thu, 20 Jul 2023 16:12:14 -0400 Message-ID: X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Recently we've been having mysterious hangs while running generic/475 on the CI system. This turned out to be something like this Task 1 dmsetup suspend --nolockfs -> __dm_suspend -> dm_wait_for_completion -> dm_wait_for_bios_completion -> Unable to complete because of IO's on a plug in Task 2 Task 2 wb_workfn -> wb_writeback -> blk_start_plug -> writeback_sb_inodes -> Infinite loop unable to make an allocation Task 3 cache_block_group ->read_extent_buffer_pages ->Waiting for IO to complete that can't be submitted because Task 1 suspended the DM device The problem here is that we need Task 2 to be scheduled completely for the blk plug to flush. Normally this would happen, we normally wait for the block group caching to finish (Task 3), and this schedule would result in the block plug flushing. However if there's enough free space available from the current caching to satisfy the allocation we won't actually wait for the caching to complete. This check however just checks that we have enough space, not that we can make the allocation. In this particular case we were trying to allocate 9mib, and we had 10mib of free space, but we didn't have 9mib of contiguous space to allocate, and thus the allocation failed and we looped. We specifically don't cycle through the FFE loop until we stop finding cached block groups because we don't want to allocate new block groups just because we're caching, so we short circuit the normal loop once we hit LOOP_CACHING_WAIT and we found a caching block group. This is normally fine, except in this particular case where the caching thread can't make progress because the dm device has been suspended. Fix this by adding another LOOP state that specifically waits for the block group to be completely cached before proceeding. This allows us to drop this particular optimization, and will give us the proper scheduling needed to finish the plug. The alternative here was to simply flush the plug if we need_resched(), but this is actually a sort of bad behavior from us where we assume that if the block group has enough free space to match our allocation we'll actually be successful. It is a good enough check for a quick pass to avoid the latency of a full wait, but free space != contiguous free space, so waiting is more appropriate. Signed-off-by: Josef Bacik --- fs/btrfs/extent-tree.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 04ceb9d25d3e..2850bd411a0e 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -3331,6 +3331,7 @@ int btrfs_free_extent(struct btrfs_trans_handle *trans, struct btrfs_ref *ref) enum btrfs_loop_type { LOOP_CACHING_NOWAIT, LOOP_CACHING_WAIT, + LOOP_CACHING_DONE, LOOP_UNSET_SIZE_CLASS, LOOP_ALLOC_CHUNK, LOOP_WRONG_SIZE_CLASS, @@ -3920,9 +3921,6 @@ static int find_free_extent_update_loop(struct btrfs_fs_info *fs_info, return 0; } - if (ffe_ctl->loop >= LOOP_CACHING_WAIT && ffe_ctl->have_caching_bg) - return 1; - ffe_ctl->index++; if (ffe_ctl->index < BTRFS_NR_RAID_TYPES) return 1; @@ -3931,6 +3929,8 @@ static int find_free_extent_update_loop(struct btrfs_fs_info *fs_info, * LOOP_CACHING_NOWAIT, search partially cached block groups, kicking * caching kthreads as we move along * LOOP_CACHING_WAIT, search everything, and wait if our bg is caching + * LOOP_CACHING_DONE, search everything, wait for the caching to + * completely finish * LOOP_UNSET_SIZE_CLASS, allow unset size class * LOOP_ALLOC_CHUNK, force a chunk allocation and try again * LOOP_NO_EMPTY_SIZE, set empty_size and empty_cluster to 0 and try @@ -3939,13 +3939,13 @@ static int find_free_extent_update_loop(struct btrfs_fs_info *fs_info, if (ffe_ctl->loop < LOOP_NO_EMPTY_SIZE) { ffe_ctl->index = 0; /* - * We want to skip the LOOP_CACHING_WAIT step if we don't have + * We want to skip the LOOP_CACHING_* steps if we don't have * any uncached bgs and we've already done a full search * through. */ if (ffe_ctl->loop == LOOP_CACHING_NOWAIT && (!ffe_ctl->orig_have_caching_bg && full_search)) - ffe_ctl->loop++; + ffe_ctl->loop = LOOP_CACHING_DONE; ffe_ctl->loop++; if (ffe_ctl->loop == LOOP_ALLOC_CHUNK) { @@ -4269,8 +4269,11 @@ static noinline int find_free_extent(struct btrfs_root *root, trace_find_free_extent_have_block_group(root, ffe_ctl, block_group); ffe_ctl->cached = btrfs_block_group_done(block_group); if (unlikely(!ffe_ctl->cached)) { - ffe_ctl->have_caching_bg = true; - ret = btrfs_cache_block_group(block_group, false); + bool wait = ffe_ctl->loop == LOOP_CACHING_DONE; + + if (!wait) + ffe_ctl->have_caching_bg = true; + ret = btrfs_cache_block_group(block_group, wait); /* * If we get ENOMEM here or something else we want to @@ -4285,6 +4288,9 @@ static noinline int find_free_extent(struct btrfs_root *root, ret = 0; goto loop; } + + if (wait) + ffe_ctl->cached = btrfs_block_group_done(block_group); ret = 0; } From patchwork Thu Jul 20 20:12:15 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 13321025 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 27198EB64DA for ; Thu, 20 Jul 2023 20:12:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230483AbjGTUMa (ORCPT ); Thu, 20 Jul 2023 16:12:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57640 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230477AbjGTUM0 (ORCPT ); Thu, 20 Jul 2023 16:12:26 -0400 Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AD38A270A for ; Thu, 20 Jul 2023 13:12:25 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id af79cd13be357-76754b9eac0so119375185a.0 for ; Thu, 20 Jul 2023 13:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20221208.gappssmtp.com; s=20221208; t=1689883944; x=1690488744; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=c+QjukrGisyobc4vKTijT+HclY5nUeKZgdUPoX3ROt4=; b=Jytwu/VTULNS2C6mUPpsJBuQA1ZyJyK5Baqewx9tm94K7xAZrQcgVBalZ8Un1UCXN/ IB2s5ttCfPozGjrMd8xlsqkpXti0B3vowytSKF732MmU4s1HsdocbyE6vUEs7e04rGBW wLV7KUzAouAFzyymBioEKBb8CnwgVDnpjSAuodAvSwyxCh/TjwZrf8fzF4Rt1FGjCARH cwrR7jxK4gJQD+bb/UcYFsckmYdIRqJlOdsJryRuJQ8EXdS/5gA+TbG+bXvs0xuV0E9o 8gmSoIlJyyxf/ULtdCoGcriIc013N5JyrKA27Ha1SqrJMohbc7M1Ro1W1ocXIubxFtFx uaWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689883944; x=1690488744; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=c+QjukrGisyobc4vKTijT+HclY5nUeKZgdUPoX3ROt4=; b=fVt+0zx5EJSRdUojGEG8uFbEz8RV//3nMIANPSCh5zDuI12mHT5Pu24cWv9uT0PYCh PXTyh3aCYrl1PDYhdp8LYWXwA6hKZSNNk8txYwlGvA3eHAm0OfC2QQ0JhowPnuFskPO8 1rfKVJjtG8JQBjnKh0PeHR/lB7Jq2l78zVN2XlEkznkYQJgQqtXdDrEhw5cmFxh5K5ZP ePtSrLanR/x2g5MxKxGOtadISNQOJ2W+jHpTvhxfN/upiL8Lepr8PFuM0d+qzgrhtimc ByaCt0tvBwglZIX4ujUxyfTq6a/RqLC/D/Kdu4xVuPEzoc9bSXRaVnKNxpecKtoACWU1 +tnw== X-Gm-Message-State: ABy/qLYTX5vhVhuGiUh74LePN03fOEL8g5p35Ke2Yju+GH8v0FQLC9eN VLp3YYK+2vnQEpbD5Jp75g6xylAn7cPV4dRjTfT4rQ== X-Google-Smtp-Source: APBJJlEvcj1p3XERhtzzgyd1JZypEC/KcA0+6fjz2tmiQDteZ9Py7JaS5Fg56WNzNGCatczXzV/LMQ== X-Received: by 2002:a05:620a:430e:b0:768:61e2:89a1 with SMTP id u14-20020a05620a430e00b0076861e289a1mr5183911qko.11.1689883944559; Thu, 20 Jul 2023 13:12:24 -0700 (PDT) Received: from localhost (cpe-76-182-20-124.nc.res.rr.com. [76.182.20.124]) by smtp.gmail.com with ESMTPSA id a20-20020a05620a16d400b00767dafbf282sm594901qkn.12.2023.07.20.13.12.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jul 2023 13:12:24 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 2/3] btrfs: move comments to btrfs_loop_type definition Date: Thu, 20 Jul 2023 16:12:15 -0400 Message-ID: <6abfcd8c6763baf92199be9532db3bd9e9e0e418.1689883754.git.josef@toxicpanda.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Some of these loop types aren't described, and they should be with the definitions to make it easier to tell what each of them do. Signed-off-by: Josef Bacik Reviewed-by: Boris Burkov --- fs/btrfs/extent-tree.c | 42 +++++++++++++++++++++++++++++++++--------- 1 file changed, 33 insertions(+), 9 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 2850bd411a0e..8db2673948c9 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -3329,12 +3329,44 @@ int btrfs_free_extent(struct btrfs_trans_handle *trans, struct btrfs_ref *ref) } enum btrfs_loop_type { + /* + * Start caching block groups but do not wait for progress or for them + * to be done. + */ LOOP_CACHING_NOWAIT, + + /* + * Wait for the block group free_space >= the space we're waiting for if + * the block group isn't cached. + */ LOOP_CACHING_WAIT, + + /* + * Wait for the block group to be completely cached before attempting to + * make an allocation. + */ LOOP_CACHING_DONE, + + /* + * Allow allocations to happen from block groups that do not yet have a + * size classification. + */ LOOP_UNSET_SIZE_CLASS, + + /* + * Allocate a chunk and then retry the allocation. + */ LOOP_ALLOC_CHUNK, + + /* + * Ignore the size class restrictions for this allocation. + */ LOOP_WRONG_SIZE_CLASS, + + /* + * Ignore the empty size, only try to allocate the number of bytes + * needed for this allocation. + */ LOOP_NO_EMPTY_SIZE, }; @@ -3926,15 +3958,7 @@ static int find_free_extent_update_loop(struct btrfs_fs_info *fs_info, return 1; /* - * LOOP_CACHING_NOWAIT, search partially cached block groups, kicking - * caching kthreads as we move along - * LOOP_CACHING_WAIT, search everything, and wait if our bg is caching - * LOOP_CACHING_DONE, search everything, wait for the caching to - * completely finish - * LOOP_UNSET_SIZE_CLASS, allow unset size class - * LOOP_ALLOC_CHUNK, force a chunk allocation and try again - * LOOP_NO_EMPTY_SIZE, set empty_size and empty_cluster to 0 and try - * again + * See the comment for btrfs_loop_type for an explanation of the phases. */ if (ffe_ctl->loop < LOOP_NO_EMPTY_SIZE) { ffe_ctl->index = 0; From patchwork Thu Jul 20 20:12:16 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 13321026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4E655C001DC for ; Thu, 20 Jul 2023 20:12:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230046AbjGTUMb (ORCPT ); Thu, 20 Jul 2023 16:12:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57630 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229603AbjGTUM1 (ORCPT ); Thu, 20 Jul 2023 16:12:27 -0400 Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D48EBED for ; Thu, 20 Jul 2023 13:12:26 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id af79cd13be357-76754b9eac0so119376585a.0 for ; Thu, 20 Jul 2023 13:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20221208.gappssmtp.com; s=20221208; t=1689883946; x=1690488746; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:from:to:cc:subject:date:message-id :reply-to; bh=pZR+LiEcuS9PmOI+xgU2ABdulN5k7XvyvVG58kN/6DE=; b=yibZxlISgBKUpJ/hnUePef62/XfjZxAg3IlUAUHVs9EAYfPMoyj6ObP1vJQ7neMyjb /+L3Vb+6XiZJAv+Y++g9Qm+qsgfREimDZ7XY3+hmiJQKiCxFpaSrI0Wo7nMfR/Cyg+Zl lHcbQXSsIgnSxbyCMM1luaA3n6uM0IB57nH5GtI1XL2qzOP4ZTPRNEdKbuvsaM4mAGlv 3hju66CWNSkI8merknetduuZuOQxk3iQUe/9tHYF+eyu9ye/7c87vMWF5IVbCuATdGVE rdIB790lh51HsrvG6pAoMwCLP2ZzdYmC5g41S67Z48MSr0IIcLTP6GqXr8li8eAKOTiI zYBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689883946; x=1690488746; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=pZR+LiEcuS9PmOI+xgU2ABdulN5k7XvyvVG58kN/6DE=; b=O6RScKIdYtEdVdjXeJItlYPR7VHaI2RsuQia7299UeZAVGiUQNqrSuKgUi7kgFXE8C zNrjSsBBxS5enug8a0hxiUh2axJ8IvRVSrXcT3ovEa9F57I+bukqyGaRUtj/2ab4aG0x ucKNenjtrVJ39n9RbOIIhZ5ESaDVD3zA3smHvOkwLtINfgWbyPKkqM1zzAmV91XTw1SR clrytsoYdgYBiU2ym9FI8azAeFTNUz/2jCRQfA23Vz3+4yKDxl7z7eoV3rNay3D7QUt4 FlWnebAMeDfaMgnh+DfgHT4lFQyrdLQibsEb9n+SHBHrBnxmEmz06uwo01y06rzCkGPU 3jjQ== X-Gm-Message-State: ABy/qLbVRfGZhWLfi9uaQ3DeMgcSYQZ2bryQHnN/boPxCs7Ao86zIz50 nW+gHW0OqwA+/6BO7ngqLb6qFf9X6rTuysOViHEo6w== X-Google-Smtp-Source: APBJJlElWFlM0Ev87P/V9HE2UthxmkyJ0v0dT2dZAKbWW8VIS4AZFbfEW7N9ez2EQU4+pZO3GgSWug== X-Received: by 2002:a05:620a:424f:b0:768:129b:b1c8 with SMTP id w15-20020a05620a424f00b00768129bb1c8mr8035731qko.38.1689883945646; Thu, 20 Jul 2023 13:12:25 -0700 (PDT) Received: from localhost (cpe-76-182-20-124.nc.res.rr.com. [76.182.20.124]) by smtp.gmail.com with ESMTPSA id g30-20020a0caade000000b006365b23b5dfsm701887qvb.23.2023.07.20.13.12.25 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jul 2023 13:12:25 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 3/3] btrfs: cycle through the RAID profiles as a last resort Date: Thu, 20 Jul 2023 16:12:16 -0400 Message-ID: <4beedde9b4f6adf4a7054707617f8784e5ee8b35.1689883754.git.josef@toxicpanda.com> X-Mailer: git-send-email 2.41.0 In-Reply-To: References: MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org Instead of looping through the RAID indices before advancing the FFE loop lets move this until after we've exhausted the entire FFE loop in order to give us the highest chance of success in satisfying the allocation based on its flags. Signed-off-by: Josef Bacik --- fs/btrfs/extent-tree.c | 9 +++++---- 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 8db2673948c9..ca4277ec1b19 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -3953,10 +3953,6 @@ static int find_free_extent_update_loop(struct btrfs_fs_info *fs_info, return 0; } - ffe_ctl->index++; - if (ffe_ctl->index < BTRFS_NR_RAID_TYPES) - return 1; - /* * See the comment for btrfs_loop_type for an explanation of the phases. */ @@ -4026,6 +4022,11 @@ static int find_free_extent_update_loop(struct btrfs_fs_info *fs_info, } return 1; } + + ffe_ctl->index++; + if (ffe_ctl->index < BTRFS_NR_RAID_TYPES) + return 1; + return -ENOSPC; }