From patchwork Thu Aug 22 19:19:00 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 11109883 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 84B7E13A4 for ; Thu, 22 Aug 2019 19:19:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6462E23400 for ; Thu, 22 Aug 2019 19:19:10 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=toxicpanda-com.20150623.gappssmtp.com header.i=@toxicpanda-com.20150623.gappssmtp.com header.b="QhnEBSR2" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391067AbfHVTTJ (ORCPT ); Thu, 22 Aug 2019 15:19:09 -0400 Received: from mail-yw1-f68.google.com ([209.85.161.68]:33752 "EHLO mail-yw1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731916AbfHVTTJ (ORCPT ); Thu, 22 Aug 2019 15:19:09 -0400 Received: by mail-yw1-f68.google.com with SMTP id e65so2866031ywh.0 for ; Thu, 22 Aug 2019 12:19:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=/82dJtG6j4UinFr+ajepKyt3y80xsdKCj96j2xkugQI=; b=QhnEBSR2h+TGx0xB9EybYkTl7kTxcoh8WuPPuu0pyq0gOUv9Q5f75asXyXSmZ3U4wm qC5lKs+jxs0qcWsJcgTm4ylnoLXJPmwIyRGVHtaYpiS0YAWYL8p+f2zj7fpBi9VuhtG7 yyJj6B84seNTS4e+2RI5vTc5mcv1+5Gxn+REdSLF4fXdlK+3+mKpANMW1O3fXLN75GOR yZgY7PqbAMMlzc/zky15rhTRFpFYKcO6fM79f5ijYA15noUyE3idjRD6FmyaBJRkZ2iA 7UM0aoE7l1y8n7uVrBR2RFicrd6LAbieus1jlZRKULBldUuuTEiLhYumvkHI6zPsY18G PGfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=/82dJtG6j4UinFr+ajepKyt3y80xsdKCj96j2xkugQI=; b=O5HIiCNxQSe2r3+nQjaHXqAhRvSXjzqarXHFZE/bzsKPTQufNKz5QHxvWvGQgZ5M5f 2qVF+cT1+PBvD+FY+c82QB6RP2c7ZuMI9cbvARI8tkwrpOtlsmomVcsBS0eUVgrda+ir C/UtzTK68JR4KGObx0LXQQrsHdJJY75/WydOcdEF97CcA/veeTMDFV042x9DrbLHTmVx At6ja0JvTTs9AbV5QfbN7VjX/quYpM1X6qq0h++QGL4sw2Ze9LJTnwhHW4yxJYUO3EjQ Ndt7yuydwrX58chZJ0enBqgg5inUK9A7P1OnV8ac3OuRbV05vR28qijgk92Eufv77L4W qUrQ== X-Gm-Message-State: APjAAAViYe92huzQQwnoB4BFT/lKM9HIKEOiLGNnJitYK2h11B5f287u 2UUplg7TTeS8qGzdhC8tVcVTJFkk2N1HhA== X-Google-Smtp-Source: APXvYqz9+Ox3OkkfxkcOWB97Sj/DQ7vkeMM2ZipZRp8nZ5urOUWtzlrJtDp6QET3N/CbF3Ei1ZRLyA== X-Received: by 2002:a81:1d84:: with SMTP id d126mr664003ywd.199.1566501548294; Thu, 22 Aug 2019 12:19:08 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id d191sm278913ywh.12.2019.08.22.12.19.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2019 12:19:07 -0700 (PDT) From: Josef Bacik To: kernel-team@fb.com, linux-btrfs@vger.kernel.org Subject: [PATCH 1/5] btrfs: change the minimum global reserve size Date: Thu, 22 Aug 2019 15:19:00 -0400 Message-Id: <20190822191904.13939-2-josef@toxicpanda.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190822191904.13939-1-josef@toxicpanda.com> References: <20190822191904.13939-1-josef@toxicpanda.com> MIME-Version: 1.0 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org It made sense to have the global reserve set at 16M in the past, but since it is used less nowadays set the minimum size to the number of items we'll need to update the main trees we update during a transaction commit, plus some slop area so we can do unlinks if we need to. In practice this doesn't affect normal file systems, but for xfstests where we do things like fill up a fs and then rm * it can fall over in weird ways. This enables us for more sane behavior at extremely small file system sizes. Signed-off-by: Josef Bacik --- fs/btrfs/block-rsv.c | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/fs/btrfs/block-rsv.c b/fs/btrfs/block-rsv.c index 60f313888a7d..76be1d978c36 100644 --- a/fs/btrfs/block-rsv.c +++ b/fs/btrfs/block-rsv.c @@ -259,6 +259,7 @@ void btrfs_update_global_block_rsv(struct btrfs_fs_info *fs_info) struct btrfs_block_rsv *block_rsv = &fs_info->global_block_rsv; struct btrfs_space_info *sinfo = block_rsv->space_info; u64 num_bytes; + unsigned min_items; /* * The global block rsv is based on the size of the extent tree, the @@ -268,7 +269,26 @@ void btrfs_update_global_block_rsv(struct btrfs_fs_info *fs_info) num_bytes = btrfs_root_used(&fs_info->extent_root->root_item) + btrfs_root_used(&fs_info->csum_root->root_item) + btrfs_root_used(&fs_info->tree_root->root_item); - num_bytes = max_t(u64, num_bytes, SZ_16M); + + /* + * We at a minimum are going to modify the csum root, the tree root, and + * the extent root. + */ + min_items = 3; + + /* + * But we also want to reserve enough space so we can do the fallback + * global reserve for an unlink, which is an additional 5 items (see the + * comment in __unlink_start_trans for what we're modifying.) + * + * But we also need space for the delayed ref updates from the unlink, + * so its 10, 5 for the actual operation, and 5 for the delayed ref + * updates. + */ + min_items += 10; + + num_bytes = max_t(u64, num_bytes, + btrfs_calc_insert_metadata_size(fs_info, min_items)); spin_lock(&sinfo->lock); spin_lock(&block_rsv->lock); From patchwork Thu Aug 22 19:19:01 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 11109885 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 70B4C13A4 for ; Thu, 22 Aug 2019 19:19:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 50DB023400 for ; Thu, 22 Aug 2019 19:19:12 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=toxicpanda-com.20150623.gappssmtp.com header.i=@toxicpanda-com.20150623.gappssmtp.com header.b="j8XJ3Dkg" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2391854AbfHVTTL (ORCPT ); Thu, 22 Aug 2019 15:19:11 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:36050 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731916AbfHVTTK (ORCPT ); Thu, 22 Aug 2019 15:19:10 -0400 Received: by mail-qt1-f196.google.com with SMTP id z4so9011208qtc.3 for ; Thu, 22 Aug 2019 12:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=1o8IieOmo6+2IKl2pwbvEjA8/yPZzaeiP3so2okpJGU=; b=j8XJ3Dkg170UAkhTRF4WN5d3WKAcwJRaZ9UBWoBxiqxooHuwlhvgKIndIVe7FR8ZKj rrxGJrQONhMjx3pR+OarzYoHMTYmBy4pR1qTzYR87yHAk2sK07HcosvpEVaquTz+iASs XHCijTkkg032l63X+7qNhAWhjw5MW4ltMO+GkktKBhuZDxvHadgXNZMdPa3b6Xx8c8M6 Kp5m4DtGdVDV4x3M/Hwl8ma2/sOF1/aipAqxdAdMeDL82NC5vj3fasZcHJU6jABLgYrg GyqQK/befwv5OSUQK2U+Yju/0bPE5qcD9YD3lBbQyb+Q2qBoUcpn2Ns+40GDsLzZ7z6Z mVEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=1o8IieOmo6+2IKl2pwbvEjA8/yPZzaeiP3so2okpJGU=; b=ZsgcYQTk17RhGglDxk79othdaNfIn0bqkUmeFU3fWbj8A5bGI2NAMKGk+LT8znTrZa 7xLzAA+K0fTx+bIO1gR1c3cdsmBoRs5JVKNZkH8wUj2lSFrwwvlZljxO/s8BZUHZLq9y /7/aU3gPDrdkAiZG1DDlRenTW87rCV9aVnEsi7XAP7IqCYpv2eINtE0WDO9I2uNLkVHz qbcj3oXaEjisjTBFcib5su2C1jKjlikNmxe1gJrOXjlWSKzuiYZz4wmsG6eFwdcFSkSY UF17XU26ExAuf9iDho1kYtbN8xwRlXl8UW+JT3vMYAHj/7QAZPJVaZ3b//ykyIHp/ThE xNJA== X-Gm-Message-State: APjAAAWBMyLjunjCLaqjJo8hIaejYrN38CeLuVdvgz2MU267LptmAgXn gNVyHb0ZPSImbDcjojija61iJA== X-Google-Smtp-Source: APXvYqw8HDTNhbu9mCSNLcwA9JbUQci6tnfFGrWN7ZjO1kpJ9VeYpM0jQFpmeq35XTg/RpcpkDPJKQ== X-Received: by 2002:ac8:64a:: with SMTP id e10mr1290355qth.30.1566501549873; Thu, 22 Aug 2019 12:19:09 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id s27sm283609qkm.129.2019.08.22.12.19.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2019 12:19:09 -0700 (PDT) From: Josef Bacik To: kernel-team@fb.com, linux-btrfs@vger.kernel.org Cc: Nikolay Borisov Subject: [PATCH 2/5] btrfs: always reserve our entire size for the global reserve Date: Thu, 22 Aug 2019 15:19:01 -0400 Message-Id: <20190822191904.13939-3-josef@toxicpanda.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190822191904.13939-1-josef@toxicpanda.com> References: <20190822191904.13939-1-josef@toxicpanda.com> MIME-Version: 1.0 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org While messing with the overcommit logic I noticed that sometimes we'd ENOSPC out when really we should have run out of space much earlier. It turns out it's because we'll only reserve up to the free amount left in the space info for the global reserve, but that doesn't make sense with overcommit because we could be well above our actual size. This results in the global reserve not carving out it's entire reservation, and thus not putting enough pressure on the rest of the infrastructure to do the right thing and ENOSPC out at a convenient time. Fix this by always taking our full reservation amount for the global reserve. Signed-off-by: Josef Bacik Reviewed-by: Nikolay Borisov --- fs/btrfs/block-rsv.c | 13 ++++--------- 1 file changed, 4 insertions(+), 9 deletions(-) diff --git a/fs/btrfs/block-rsv.c b/fs/btrfs/block-rsv.c index 76be1d978c36..67071bb8e433 100644 --- a/fs/btrfs/block-rsv.c +++ b/fs/btrfs/block-rsv.c @@ -296,15 +296,10 @@ void btrfs_update_global_block_rsv(struct btrfs_fs_info *fs_info) block_rsv->size = min_t(u64, num_bytes, SZ_512M); if (block_rsv->reserved < block_rsv->size) { - num_bytes = btrfs_space_info_used(sinfo, true); - if (sinfo->total_bytes > num_bytes) { - num_bytes = sinfo->total_bytes - num_bytes; - num_bytes = min(num_bytes, - block_rsv->size - block_rsv->reserved); - block_rsv->reserved += num_bytes; - btrfs_space_info_update_bytes_may_use(fs_info, sinfo, - num_bytes); - } + num_bytes = block_rsv->size - block_rsv->reserved; + block_rsv->reserved += num_bytes; + btrfs_space_info_update_bytes_may_use(fs_info, sinfo, + num_bytes); } else if (block_rsv->reserved > block_rsv->size) { num_bytes = block_rsv->reserved - block_rsv->size; btrfs_space_info_update_bytes_may_use(fs_info, sinfo, From patchwork Thu Aug 22 19:19:02 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 11109887 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 508131399 for ; Thu, 22 Aug 2019 19:19:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2FE4A23400 for ; Thu, 22 Aug 2019 19:19:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=toxicpanda-com.20150623.gappssmtp.com header.i=@toxicpanda-com.20150623.gappssmtp.com header.b="1rLLcqNd" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404040AbfHVTTN (ORCPT ); Thu, 22 Aug 2019 15:19:13 -0400 Received: from mail-qk1-f194.google.com ([209.85.222.194]:39470 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731916AbfHVTTM (ORCPT ); Thu, 22 Aug 2019 15:19:12 -0400 Received: by mail-qk1-f194.google.com with SMTP id 125so6158154qkl.6 for ; Thu, 22 Aug 2019 12:19:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=uJex6zvA+bgVAiBQ5FAdnkxekTPugn+ezm0BsuIlrbA=; b=1rLLcqNdC0Zr2nT9fl0DcUYui0Hpe4Erp733dmR/wEuAyT6ynNpUryyPlLErsJ5+ZG GkzP/pYWthbPThFC8MMFOSoYjjIcnyQ2zJUdznVGlTBRxjbw4fLaJM0QIzDuVR9OtsSy 6Bmg3jNxz2X0KW4nOKSZuBIK45hbGiyuDNrDN6FmVEKHAxAujhqYf4OTArmy+nxT1doG aIjHl8J9u57dbwzPaVpYuYZEd8C0F6x3Grym01oR2BhIvB4eYdf+wRXd4nj3N7U8hNQC 4+Cc1LGIpfIlVKwqtrJujxqBheN0qaJawL99+/2ugDnl2Ym+r+bsKP4zDboTl3VKAs8S e74g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=uJex6zvA+bgVAiBQ5FAdnkxekTPugn+ezm0BsuIlrbA=; b=awtmU1QH8T24ta7p+zKAJI1x9FiRHDb+X5AFVb69SsRJXEJnC1PHTnv1KJZCWMObal 2+pQ7sBrH1hfuEKja+1InzPwWyqmYQ7dhNsl4KSu1iPkeTZdBeRVRw7ke0ujbTgBXx/l +3Jcpqfp4jjk+XChD7JGYW9O8l3PObL4gXAdX6Ni80WeSl8ZG3g2vISmLCy6SGyYrBvn yhHWi8kGLJDRgHIyXf9yURt1lmseF2+96WcsFl5hwQrZxX2JrHuCl1vd5V8Fa8wkdS1f 8GgZBA2n4gotQvZdsUSMdXX3oBTBpYdUzVTkIjUQqvCszUK9v1y6mMO8bSSpBSmmJFf6 AMMw== X-Gm-Message-State: APjAAAWj0snO8hbEqWvuqiA7U+4FGb3oqkE05KDLcZJRdWz0L6Jf574g UOV1n7XHE+xSLLKlOru0rMZUKg== X-Google-Smtp-Source: APXvYqx56KrV7JR9tYMuTYJPfigLj3K+9mFovkcy4TLuMl5l5UvQmJWDO0sRx/5WyUtot39VDVJ2wg== X-Received: by 2002:a37:8844:: with SMTP id k65mr545773qkd.77.1566501551676; Thu, 22 Aug 2019 12:19:11 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id b13sm232557qtk.55.2019.08.22.12.19.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2019 12:19:11 -0700 (PDT) From: Josef Bacik To: kernel-team@fb.com, linux-btrfs@vger.kernel.org Cc: Nikolay Borisov Subject: [PATCH 3/5] btrfs: use btrfs_try_granting_tickets in update_global_rsv Date: Thu, 22 Aug 2019 15:19:02 -0400 Message-Id: <20190822191904.13939-4-josef@toxicpanda.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190822191904.13939-1-josef@toxicpanda.com> References: <20190822191904.13939-1-josef@toxicpanda.com> MIME-Version: 1.0 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org We have some annoying xfstests tests that will create a very small fs, fill it up, delete it, and repeat to make sure everything works right. This trips btrfs up sometimes because we may commit a transaction to free space, but most of the free metadata space was being reserved by the global reserve. So we commit and update the global reserve, but the space is simply added to bytes_may_use directly, instead of trying to add it to existing tickets. This results in ENOSPC when we really did have space. Fix this by calling btrfs_try_granting_tickets once we add back our excess space to wake any pending tickets. Signed-off-by: Josef Bacik Reviewed-by: Nikolay Borisov --- fs/btrfs/block-rsv.c | 1 + 1 file changed, 1 insertion(+) diff --git a/fs/btrfs/block-rsv.c b/fs/btrfs/block-rsv.c index 67071bb8e433..a292866221b0 100644 --- a/fs/btrfs/block-rsv.c +++ b/fs/btrfs/block-rsv.c @@ -305,6 +305,7 @@ void btrfs_update_global_block_rsv(struct btrfs_fs_info *fs_info) btrfs_space_info_update_bytes_may_use(fs_info, sinfo, -num_bytes); block_rsv->reserved = block_rsv->size; + btrfs_try_granting_tickets(fs_info, sinfo); } if (block_rsv->reserved == block_rsv->size) From patchwork Thu Aug 22 19:19:03 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 11109889 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D88F013A4 for ; Thu, 22 Aug 2019 19:19:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B7CA023400 for ; Thu, 22 Aug 2019 19:19:15 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=toxicpanda-com.20150623.gappssmtp.com header.i=@toxicpanda-com.20150623.gappssmtp.com header.b="sRJ2PgaG" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404053AbfHVTTO (ORCPT ); Thu, 22 Aug 2019 15:19:14 -0400 Received: from mail-yb1-f195.google.com ([209.85.219.195]:34269 "EHLO mail-yb1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731916AbfHVTTO (ORCPT ); Thu, 22 Aug 2019 15:19:14 -0400 Received: by mail-yb1-f195.google.com with SMTP id u68so2983098ybg.1 for ; Thu, 22 Aug 2019 12:19:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=AeR79+V8X3o9J1ucanG1LzY/IGLduXL++6IRQRmHGIE=; b=sRJ2PgaGBlszTXL2a2xRFH2uvv1byIQHOYOuYscxwFz5RnoSw165kuvSrWxckVSL+S ZmDXE9JArHZZm7tMq3XZo35yZrdDY+YE1njba6zpeW3G+qce/6KjeDuM2Q+cuaU4sr28 EfEnQGq4MolafBYJ1OX0HismwI/P4VThsIzcOT6MgSIk2E3737VKKefyLOPoJcORoXKq qsa1HI1KshBXG8qaIXY+eaa5yZjihOdIZxKtE3RqfK0LmUqhdIru1dlqWbBmH71fAId6 ULc/C1vhz/llwsmDlbnibtCf4MVK0U6wlDZGG8Ar8jGn1Oc7r8orkUigwwAeMGVTYSDy MxKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=AeR79+V8X3o9J1ucanG1LzY/IGLduXL++6IRQRmHGIE=; b=NdH1e0Pmsghr6qKEVHQGUSQQXX9OtGNmVMNKFyFqk6ojot1zBgAzCjCLqr4BcVv3Eh zmmSvXUU1a6IvbebkQTHBghFGUZOZIJ5ED8TpZzzBy1rmRSKKx1wyBZsEROFahteP3Xh bN2X5bwVQlXaBr/gr43qSpyHi4F/hFFhYNFA2Gahk0iqwy9nfvz7tY34ZjSnUk6tpXzn yAmo12P+gfSct/zXx/kACKrlznjiCwRrRtx3pHuCFzXLdZRxdUUfFg0pbmanfU45yufr Iv+QCVde8EpAGCBQif/M83bA0l/wxZOgShAmhfjVeZkdNRV7aQJnx0nEK5rbmzH6MxVK jB0w== X-Gm-Message-State: APjAAAVE21o41cIORhPvOGouhlms/gWTc5mKkzN1vBG91Zd+jhIa7338 DB50Kw9P8VBUY72p/1aQJtrunOOJ+iCnyQ== X-Google-Smtp-Source: APXvYqwT4p6aCqIydgmxHjFuF6ZBMOxYPzq3v69O/nuup741wLZxk8zNRZGhDmhM9iotCpU1jfJgXg== X-Received: by 2002:a05:6902:4f1:: with SMTP id w17mr446478ybs.36.1566501553243; Thu, 22 Aug 2019 12:19:13 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id y3sm105861ywa.47.2019.08.22.12.19.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2019 12:19:12 -0700 (PDT) From: Josef Bacik To: kernel-team@fb.com, linux-btrfs@vger.kernel.org Cc: Nikolay Borisov Subject: [PATCH 4/5] btrfs: do not account global reserve in can_overcommit Date: Thu, 22 Aug 2019 15:19:03 -0400 Message-Id: <20190822191904.13939-5-josef@toxicpanda.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190822191904.13939-1-josef@toxicpanda.com> References: <20190822191904.13939-1-josef@toxicpanda.com> MIME-Version: 1.0 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org We ran into a problem in production where a box with plenty of space was getting wedged doing ENOSPC flushing. These boxes only had 20% of the disk allocated, but their metadata space + global reserve was right at the size of their metadata chunk. In this case can_overcommit should be allowing allocations without problem, but there's logic in can_overcommit that doesn't allow us to overcommit if there's not enough real space to satisfy the global reserve. This is for historical reasons. Before there were only certain places we could allocate chunks. We could go to commit the transaction and not have enough space for our pending delayed refs and such and be unable to allocate a new chunk. This would result in a abort because of ENOSPC. This code was added to solve this problem. However since then we've gained the ability to always be able to allocate a chunk. So we can easily overcommit in these cases without risking a transaction abort because of ENOSPC. Also prior to now the global reserve really would be used because that's the space we relied on for delayed refs. With delayed refs being tracked separately we no longer have to worry about running out of delayed refs space while committing. We are much less likely to exhaust our global reserve space during transaction commit. Fix the can_overcommit code to simply see if our current usage + what we want is less than our current free space plus whatever slack space we have in the disk is. This solves the problem we were seeing in production and keeps us from flushing as aggressively as we approach our actual metadata size usage. Signed-off-by: Josef Bacik Reviewed-by: Nikolay Borisov --- fs/btrfs/space-info.c | 19 +------------------ 1 file changed, 1 insertion(+), 18 deletions(-) diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c index a43f6287074b..3053b3e91b34 100644 --- a/fs/btrfs/space-info.c +++ b/fs/btrfs/space-info.c @@ -165,9 +165,7 @@ static int can_overcommit(struct btrfs_fs_info *fs_info, enum btrfs_reserve_flush_enum flush, bool system_chunk) { - struct btrfs_block_rsv *global_rsv = &fs_info->global_block_rsv; u64 profile; - u64 space_size; u64 avail; u64 used; int factor; @@ -181,22 +179,7 @@ static int can_overcommit(struct btrfs_fs_info *fs_info, else profile = btrfs_metadata_alloc_profile(fs_info); - used = btrfs_space_info_used(space_info, false); - - /* - * We only want to allow over committing if we have lots of actual space - * free, but if we don't have enough space to handle the global reserve - * space then we could end up having a real enospc problem when trying - * to allocate a chunk or some other such important allocation. - */ - spin_lock(&global_rsv->lock); - space_size = calc_global_rsv_need_space(global_rsv); - spin_unlock(&global_rsv->lock); - if (used + space_size >= space_info->total_bytes) - return 0; - - used += space_info->bytes_may_use; - + used = btrfs_space_info_used(space_info, true); avail = atomic64_read(&fs_info->free_chunk_space); /* From patchwork Thu Aug 22 19:19:04 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 11109891 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id A588D13A4 for ; Thu, 22 Aug 2019 19:19:17 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8519223400 for ; Thu, 22 Aug 2019 19:19:17 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=toxicpanda-com.20150623.gappssmtp.com header.i=@toxicpanda-com.20150623.gappssmtp.com header.b="RqBjyseQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2404054AbfHVTTQ (ORCPT ); Thu, 22 Aug 2019 15:19:16 -0400 Received: from mail-yw1-f66.google.com ([209.85.161.66]:35770 "EHLO mail-yw1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731916AbfHVTTP (ORCPT ); Thu, 22 Aug 2019 15:19:15 -0400 Received: by mail-yw1-f66.google.com with SMTP id g19so2865940ywe.2 for ; Thu, 22 Aug 2019 12:19:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=JCeHqJn5hWvaulbgtXjkznoD3Mwz4/wqiCtYVGAepqY=; b=RqBjyseQ5T84wAZ2DjZPXraqeIYlpFmR0NBlno5XEgLxD2D/5fFe7GY+dgnR1VLiQN VG565eF1QWxQ2f2zmVgfWAO/YUtgaaQU+qegO5p80mZMJ63AWEHoJBPSyFQeJ7TeKmkN XgcZ98tnI97PylD0B6z4+0DgDp6adIeU1uMslp1FRssFQdmp/H8qPCBkX8gt9p7OZwcX xFoCqmjBihjCyCyAuZbzn/psFwwm2auAMcbPZ4+pJ3lriM99Vt/K0WL2PbxpkgmUx6M8 lg4sCD9dvjLWs45ES8dcaZqoQrD1RcKlTASt6qYZdINQPVDY1qLz1P1WHvJyCxzyP83d 5BHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=JCeHqJn5hWvaulbgtXjkznoD3Mwz4/wqiCtYVGAepqY=; b=akuMdLRIAtLO0AOI68gVWsA+cHJq9BvSDvh0tu3xPngMqssbQTLAiFSb07H/0qbvEv DglUaphAL/tZx+j78t8a6ByAzpLlc5LqDw68gL77s2ROEaRn6jnioH+BVJEzp62IpGkx TT4uH68LAoLWZI6q1D1T0C99OuGGDmD9/nrUshGmFKOz9/uV/WXu13dyPT67oFfG5Gs3 5OVLmrpcnCwVN/KMIEPRDnLrG3GTKZQCkKWJrf89nOfqXKtlyvEXywDAHg0Im29kjzq/ kdiQph2iHeXrOumuHVPXC36exRVL+ap9BS8CwRDqYbtI6+8ViSFRlFkBw8MfU5AunpwC FTxA== X-Gm-Message-State: APjAAAW6PfuXtfmq5nQJ1kOk4KgGgMqM/HzpALsAXaQ/iDjLdCYKAASd R//KXUZYwUva3rJxdSqwMT6dsg== X-Google-Smtp-Source: APXvYqwsg83PICBhpSErb+tOCAbi5H307mm9NqnRLAcMYsg9r99XQp1FLrWZmIb9dXVDFwM7+FfkBA== X-Received: by 2002:a81:9945:: with SMTP id q66mr718953ywg.47.1566501554988; Thu, 22 Aug 2019 12:19:14 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id b202sm125748ywb.78.2019.08.22.12.19.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Aug 2019 12:19:14 -0700 (PDT) From: Josef Bacik To: kernel-team@fb.com, linux-btrfs@vger.kernel.org Cc: Nikolay Borisov Subject: [PATCH 5/5] btrfs: add enospc debug messages for ticket failure Date: Thu, 22 Aug 2019 15:19:04 -0400 Message-Id: <20190822191904.13939-6-josef@toxicpanda.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190822191904.13939-1-josef@toxicpanda.com> References: <20190822191904.13939-1-josef@toxicpanda.com> MIME-Version: 1.0 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org When debugging weird enospc problems it's handy to be able to dump the space info when we wake up all tickets, and see what the ticket values are. This helped me figure out cases where we were enospc'ing when we shouldn't have been. Signed-off-by: Josef Bacik Reviewed-by: Nikolay Borisov --- fs/btrfs/space-info.c | 32 +++++++++++++++++++++++++------- 1 file changed, 25 insertions(+), 7 deletions(-) diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c index 3053b3e91b34..54d0f34682d8 100644 --- a/fs/btrfs/space-info.c +++ b/fs/btrfs/space-info.c @@ -258,14 +258,11 @@ do { \ spin_unlock(&__rsv->lock); \ } while (0) -void btrfs_dump_space_info(struct btrfs_fs_info *fs_info, - struct btrfs_space_info *info, u64 bytes, - int dump_block_groups) +static void __btrfs_dump_space_info(struct btrfs_fs_info *fs_info, + struct btrfs_space_info *info) { - struct btrfs_block_group_cache *cache; - int index = 0; + lockdep_assert_held(&info->lock); - spin_lock(&info->lock); btrfs_info(fs_info, "space_info %llu has %llu free, is %sfull", info->flags, info->total_bytes - btrfs_space_info_used(info, true), @@ -275,7 +272,6 @@ void btrfs_dump_space_info(struct btrfs_fs_info *fs_info, info->total_bytes, info->bytes_used, info->bytes_pinned, info->bytes_reserved, info->bytes_may_use, info->bytes_readonly); - spin_unlock(&info->lock); DUMP_BLOCK_RSV(fs_info, global_block_rsv); DUMP_BLOCK_RSV(fs_info, trans_block_rsv); @@ -283,6 +279,19 @@ void btrfs_dump_space_info(struct btrfs_fs_info *fs_info, DUMP_BLOCK_RSV(fs_info, delayed_block_rsv); DUMP_BLOCK_RSV(fs_info, delayed_refs_rsv); +} + +void btrfs_dump_space_info(struct btrfs_fs_info *fs_info, + struct btrfs_space_info *info, u64 bytes, + int dump_block_groups) +{ + struct btrfs_block_group_cache *cache; + int index = 0; + + spin_lock(&info->lock); + __btrfs_dump_space_info(fs_info, info); + spin_unlock(&info->lock); + if (!dump_block_groups) return; @@ -681,6 +690,11 @@ static bool maybe_fail_all_tickets(struct btrfs_fs_info *fs_info, u64 tickets_id = space_info->tickets_id; u64 first_ticket_bytes = 0; + if (btrfs_test_opt(fs_info, ENOSPC_DEBUG)) { + btrfs_info(fs_info, "cannot satisfy tickets, dumping space info"); + __btrfs_dump_space_info(fs_info, space_info); + } + while (!list_empty(&space_info->tickets) && tickets_id == space_info->tickets_id) { ticket = list_first_entry(&space_info->tickets, @@ -701,6 +715,10 @@ static bool maybe_fail_all_tickets(struct btrfs_fs_info *fs_info, else if (first_ticket_bytes > ticket->bytes) return true; + if (btrfs_test_opt(fs_info, ENOSPC_DEBUG)) + btrfs_info(fs_info, "failing ticket with %llu bytes", + ticket->bytes); + list_del_init(&ticket->list); ticket->error = -ENOSPC; wake_up(&ticket->wait);