From patchwork Fri Aug 16 15:20:15 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 11097873 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id D0D7456FE for ; Fri, 16 Aug 2019 15:20:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BDA2328929 for ; Fri, 16 Aug 2019 15:20:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B1A0F28911; Fri, 16 Aug 2019 15:20:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E5B4B2892B for ; Fri, 16 Aug 2019 15:20:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727527AbfHPPUZ (ORCPT ); Fri, 16 Aug 2019 11:20:25 -0400 Received: from mail-qk1-f194.google.com ([209.85.222.194]:37077 "EHLO mail-qk1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727311AbfHPPUZ (ORCPT ); Fri, 16 Aug 2019 11:20:25 -0400 Received: by mail-qk1-f194.google.com with SMTP id s14so5062000qkm.4 for ; Fri, 16 Aug 2019 08:20:24 -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=uj7RCs2MZoUADRXciWAkYJ4yzZdsQ6VBxGKx7wFHGRo=; b=hMVlLyqBzm7E89T0uOCg9eLukqUyLJSDg7oOlqDocwsHV7nFllqKeAQnkQN6UZYwgc ULQoNXx42b1yvn4ZRxETjMyit5m3LcyeV7+kP6S/ZWC4dFEdw9PbxOXQoQF7LmyH9BaT aSNARZOCHTVo6Vq6KcWKxgTRVOYszAK/ME1aYktjkWNaUhPj2OwhWDpWEmhJKyV0wZ6+ HaywOhiClRsWBMiQn7NBANvIjd9rlqBQFDA6fTtq6rQXmNuTmY1aj628tUI4l036YuXK oM1PhELUIjNsOUYQolMtl/yyNJqWMaa7lkNHYgZG4ogA7RpYtSjcNsMUlq9zeWwzSvpf LgOw== 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=uj7RCs2MZoUADRXciWAkYJ4yzZdsQ6VBxGKx7wFHGRo=; b=QMMeWtFL0I+j0xsIQ6aRrsEGwUfI3nPLqnahMhKNtpV+0FmkJqR+0YmnU0Za0Ig7mf xRpwEri/bdm1eivAZwQGzlX0CK54zKqD5o2asfJtx7WXv/Fgfn7ARKPUjHBj+uNTGgjV kSMOuvl+eWKVCrtiztZSH88xLTbff1WHztlizmH47aoTCWzYkgiFXubgnprOSr48q+0S KQpwwxbubzjQf6+EZQkHkxwhBI3ylcSXZjYJhfTFfQ1J5vlBWNTl5EpK7OZsEx3Odouf VJeroCsi9JBef+tmVV36MDl8+hSpyLF8o64Ip9OaWsGeiMjNzPv5zKoCgzLFxFkH9nHg pUzg== X-Gm-Message-State: APjAAAVunBQoec776Sf8QImCYyGZ8giOamd3+OH++V8a/ASsR67o+z+6 Dc0d6mZJy7Ct0LOIwaEwmow8UjcjOtPNLQ== X-Google-Smtp-Source: APXvYqz+hGZpkcH64ShV+LnOoR/q6B3617J5a0QTlejQZ1/0EYvK8Z0/vPFpoCvy7FqF0KO5pxe3Mg== X-Received: by 2002:a37:be41:: with SMTP id o62mr9395196qkf.356.1565968823894; Fri, 16 Aug 2019 08:20:23 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id f7sm2967275qtj.16.2019.08.16.08.20.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Aug 2019 08:20:23 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 1/5] btrfs: change the minimum global reserve size Date: Fri, 16 Aug 2019 11:20:15 -0400 Message-Id: <20190816152019.1962-2-josef@toxicpanda.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190816152019.1962-1-josef@toxicpanda.com> References: <20190816152019.1962-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 X-Virus-Scanned: ClamAV using ClamSMTP 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 c64b460a4301..657675eef443 100644 --- a/fs/btrfs/block-rsv.c +++ b/fs/btrfs/block-rsv.c @@ -258,6 +258,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 @@ -267,7 +268,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 Fri Aug 16 15:20:16 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 11097869 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 843525700 for ; Fri, 16 Aug 2019 15:20:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 744C728905 for ; Fri, 16 Aug 2019 15:20:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 68D5F28908; Fri, 16 Aug 2019 15:20:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 1154028932 for ; Fri, 16 Aug 2019 15:20:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727531AbfHPPU1 (ORCPT ); Fri, 16 Aug 2019 11:20:27 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:39978 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727311AbfHPPU0 (ORCPT ); Fri, 16 Aug 2019 11:20:26 -0400 Received: by mail-qt1-f196.google.com with SMTP id e8so6454185qtp.7 for ; Fri, 16 Aug 2019 08:20:26 -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=q46PD7UxMjoqblNZxRfqQ5JkvwrT9L9w1KjqSx+ge9s=; b=zdHetuc2myY3vnnd4J1GufMfR4gs3ZzWhBUEH+of+w0BWJo3l4KAd/LKB113BsInAw kixJC9c9C4X5MOVK/hVDvpyQE6VP1jKsXCJSZzQLMx3FJhToyMlCiCS29D3ASCmn+oHj CvjKTfQX4hEuEjVkj0XSpEzf5j9iY02vRaqHOHwjh2xsNKMSCi6k+KmWXvj6lZ9a3ip5 +aW8jcHy/BqlGGcQ9wkaD5u8/n6hpxUvuSyW0PR8miV/BqDOVlHN+lXf4y59JcMTpuPJ ukBKDUAbEVyIaOuQIgW+AACqG+ADlVHAzEQ/ttEhH88DuB2OVLWyLH/9iJh+X/AuLCtE wzHw== 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=q46PD7UxMjoqblNZxRfqQ5JkvwrT9L9w1KjqSx+ge9s=; b=rRisV5bkFrjwq1++eu/x/7R7HSYVdN1NuDw64IMs7/MaW3svH8MRRCKXfrxp9gyGcN B+5xFKai3HHOZVL/x2dttvCwdFm1IsRikAiPnIJTBhJ3PMsxVTPwbt/S9kbqINoFGEKB dkDEAjn8duRex+ekuXd+nsGFduD9BhUktMfiaqFkpSrdRhl663fxNkYtZZgtXOwB1kjP YaoDXZ+nsgXCNHjPKIKxB9b3ZqIe+D/18qLIQgDtyHzAkcm9AzNtjKR/M2+KoM+Se/dd baF8qH2Hzihfgl4MPmg1mm6PQLZ29tjYNULjEwta6hM/LcA/1CYrnJztZ6TmuTaL+npO Ujyw== X-Gm-Message-State: APjAAAXRIpu6jUyAha8z9grKXBpS0wKA0gYOt5rIogveL+RjrAmmfB4l mwDLcPzmCfGY9prlnrY4GVoJQlCLDnLUKw== X-Google-Smtp-Source: APXvYqw3o3+QFeCgIYfpzKp7sT/d9ySUZjtCOWhkxdLZlIf0J6StgVDUWZ3h+/IqWAmMuW2K0IZy4A== X-Received: by 2002:a0c:d003:: with SMTP id u3mr2243979qvg.112.1565968825603; Fri, 16 Aug 2019 08:20:25 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id r15sm3005604qkm.27.2019.08.16.08.20.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Aug 2019 08:20:25 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 2/5] btrfs: always reserve our entire size for the global reserve Date: Fri, 16 Aug 2019 11:20:16 -0400 Message-Id: <20190816152019.1962-3-josef@toxicpanda.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190816152019.1962-1-josef@toxicpanda.com> References: <20190816152019.1962-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 X-Virus-Scanned: ClamAV using ClamSMTP 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 657675eef443..18a0af20ee5a 100644 --- a/fs/btrfs/block-rsv.c +++ b/fs/btrfs/block-rsv.c @@ -295,15 +295,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 Fri Aug 16 15:20:17 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 11097871 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id BFED714F7 for ; Fri, 16 Aug 2019 15:20:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id AB6F928671 for ; Fri, 16 Aug 2019 15:20:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 9E0BA28905; Fri, 16 Aug 2019 15:20:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 334F428941 for ; Fri, 16 Aug 2019 15:20:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727536AbfHPPU3 (ORCPT ); Fri, 16 Aug 2019 11:20:29 -0400 Received: from mail-qk1-f196.google.com ([209.85.222.196]:43670 "EHLO mail-qk1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727311AbfHPPU2 (ORCPT ); Fri, 16 Aug 2019 11:20:28 -0400 Received: by mail-qk1-f196.google.com with SMTP id m2so4976908qkd.10 for ; Fri, 16 Aug 2019 08:20:28 -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=ynhRgJ4uDXwvvYSLcHfqM8iEnjxROfQZHfHlR2ApWA4=; b=0AzSjqnerkwDfB9kFWGC1BY28ApilHu+YNi0oe1F6S6evL1faS/Pr8nRtI5YfCtQnt 621hiUCI87URMhg53iGr2s+GXRqjwg6D8C/TtAPsS9y7fGPLuMkqT/HtrdyNlpcrulPc 4osDmLElzHwq8Od5+CoLeeQkJZ1K+W4rd8V1tC00P+CLMOi0Am7jMZmCHEiGRQEyTC6Y r1T9YJZerXL9DSdxFQhbTlTyia3O37BTvPwh6Jbiv8o6Dc0d9PWrzyuNPd+CqH5YHLkQ XBgXMO/R+Gc538r6vFXvc1H4revmfPjhj7A2YFWGLpgKVw4xf7TksOej3jTpKBpgWWXF 1s6g== 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=ynhRgJ4uDXwvvYSLcHfqM8iEnjxROfQZHfHlR2ApWA4=; b=Cd7FaPGsfrU5ypo4Ll8YyYHNug09orNtKBboYDpP/VqjLRKOhO12QdzYIG1BqTbMuY j/NawZ7NL+v9xTm9IhPPC/Ty1z1Sp/cn3Istnq2+P11ccD+ryno1gyWwL0c/qEUBOZUi o8uda06DyadP37PZTkLhCqol+UZbrndSF5Ac31Fhf6KUu1ZLE5pri5sBS1kfRUpnzgVh CVWhdhWPq5V3LM9ttWfEJ18EjGyjqn1AilNnPc2mqI1FbagwymYPzvCjIMZhvW5yVNi7 FNLJyKr45PvUvdYlrfBaIfWXzDqYOPJ4vlkAdUVc/6J/uu4heaJrxSnifyBieyp2rnl4 4RSA== X-Gm-Message-State: APjAAAUCExYY8D3ZchUtTKk4NDnGRhfWSTM7c8OAGSx5MjhRpNPRQALQ j1yGx1pk2gJ32xkjoMShEPNKyIP4Si5YbA== X-Google-Smtp-Source: APXvYqx5t35wi4UcMeMgmLAOMNfxPrG0eVnN+7F81eqbGSG7lqA4hpHAhFXqfVzKC+PeIibJ+NB2Mw== X-Received: by 2002:a37:b982:: with SMTP id j124mr9168482qkf.251.1565968827316; Fri, 16 Aug 2019 08:20:27 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id p126sm3454653qkc.84.2019.08.16.08.20.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Aug 2019 08:20:26 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 3/5] btrfs: use add_old_bytes when updating global reserve Date: Fri, 16 Aug 2019 11:20:17 -0400 Message-Id: <20190816152019.1962-4-josef@toxicpanda.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190816152019.1962-1-josef@toxicpanda.com> References: <20190816152019.1962-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 X-Virus-Scanned: ClamAV using ClamSMTP 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 returning the space via btrfs_space_info_add_old_bytes. The global reserve _can_ be using overcommitted space, but the add_old_bytes checks this and won't add the reservation if we're still overcommitted, so we are safe in this regard. Signed-off-by: Josef Bacik Reviewed-by: Nikolay Borisov but see below for one --- fs/btrfs/block-rsv.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/fs/btrfs/block-rsv.c b/fs/btrfs/block-rsv.c index 18a0af20ee5a..394b8fff3a4b 100644 --- a/fs/btrfs/block-rsv.c +++ b/fs/btrfs/block-rsv.c @@ -258,6 +258,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; + u64 to_free = 0; unsigned min_items; /* @@ -300,9 +301,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); } 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, - -num_bytes); + to_free = block_rsv->reserved - block_rsv->size; block_rsv->reserved = block_rsv->size; } @@ -313,6 +312,9 @@ void btrfs_update_global_block_rsv(struct btrfs_fs_info *fs_info) spin_unlock(&block_rsv->lock); spin_unlock(&sinfo->lock); + + if (to_free) + btrfs_space_info_add_old_bytes(fs_info, sinfo, to_free); } void btrfs_init_global_block_rsv(struct btrfs_fs_info *fs_info) From patchwork Fri Aug 16 15:20:18 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 11097865 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id CED8B56FE for ; Fri, 16 Aug 2019 15:20:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id BD93128929 for ; Fri, 16 Aug 2019 15:20:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id B1AB928A17; Fri, 16 Aug 2019 15:20:33 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 8A4DA2899D for ; Fri, 16 Aug 2019 15:20:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727549AbfHPPUa (ORCPT ); Fri, 16 Aug 2019 11:20:30 -0400 Received: from mail-qt1-f196.google.com ([209.85.160.196]:34072 "EHLO mail-qt1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727311AbfHPPUa (ORCPT ); Fri, 16 Aug 2019 11:20:30 -0400 Received: by mail-qt1-f196.google.com with SMTP id q4so6500911qtp.1 for ; Fri, 16 Aug 2019 08:20:29 -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=B467Ri0de2wq/UqSeJ7pK5/0NTpfGHZiwnmW7UyKD1Q=; b=VWk2pgxM2NkeOCIwNshDX24JmNnvPPl7obnqnEp6F514wR88zWwphEZiWWEDnB1NHJ BasGD65O+N++c/5Kn8D7Xf5digmOE/FFgpaTUUEFC/h8iFWPF8XmEgnZV92StZuxkGeZ Z54dnnyb5PIPy7OqnRe3zUTN3Gi3/2tnGwVK7EXgtqucK9jswTzRiuFSeEAHiQ4V8mna Z3xv3m+kQ57o7ppuqQM+0t/mBnLWvS1H/Tqxzx4q09XGM0FY/aAtz012TuNBYd5l6BDw GMqKXapfw6/vXNq8U6dVlpPqmP1kuWeuwO8JW+ou2Dk8l7vOasXV84KxOMmoFFAJ9xyI Ljsg== 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=B467Ri0de2wq/UqSeJ7pK5/0NTpfGHZiwnmW7UyKD1Q=; b=MtOz5kr+Qj4VCFyRV1csPx48Nga9jMPSDkPwgRQdY6AN61E37GwK4q1gbtXvSGicB2 UOb+ICC3AwNY/CZeAGkiNHBEI0taIFmGDK9CX7ULpMZrzPQl4cCZPr3ljvosbjoOxOdx BukKN+spWXVdvuOqkoE6Azkvxe9SW0VjqTElMDytFBT0BhtOpXEXQxd9iUtdIc3rXrYS bWkjXqZSYacdcUcFg07Yw9x0rn588HrcyoylhuCfedvtGGUtTpiy7BVJJy/Tfq889ywO ZKb8MOuIKjRPQCHeEs+rlPEir4hLxvfrPNm+Q8MbzccNSo1x90SgcKURacB49JAA64e9 nXsQ== X-Gm-Message-State: APjAAAWPj+AcZNPqUSJRML3+jCBWNQ5DJ2AwZc4Y3zdlSWUXJu1DPAJq u8RNo6elHTQ11C83gb983enU3Jh2mXnwew== X-Google-Smtp-Source: APXvYqzw2L8m1/U7AUDT/4ZERliusz+D5AqFhOHM+Jj5QMezVhagX/hTbVa9Tf1boF2R6oxOJFqijw== X-Received: by 2002:a0c:e64e:: with SMTP id c14mr2175112qvn.117.1565968828930; Fri, 16 Aug 2019 08:20:28 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id k2sm2875245qtq.84.2019.08.16.08.20.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Aug 2019 08:20:28 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 4/5] btrfs: do not account global reserve in can_overcommit Date: Fri, 16 Aug 2019 11:20:18 -0400 Message-Id: <20190816152019.1962-5-josef@toxicpanda.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190816152019.1962-1-josef@toxicpanda.com> References: <20190816152019.1962-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 X-Virus-Scanned: ClamAV using ClamSMTP 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 9c5f81074cd5..3d3f301bae26 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 Fri Aug 16 15:20:19 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 11097867 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 442B6912 for ; Fri, 16 Aug 2019 15:20:34 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 31CCD28905 for ; Fri, 16 Aug 2019 15:20:34 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1DD5E28A2D; Fri, 16 Aug 2019 15:20:34 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.9 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id A34632892A for ; Fri, 16 Aug 2019 15:20:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727555AbfHPPUc (ORCPT ); Fri, 16 Aug 2019 11:20:32 -0400 Received: from mail-qk1-f195.google.com ([209.85.222.195]:37095 "EHLO mail-qk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727311AbfHPPUb (ORCPT ); Fri, 16 Aug 2019 11:20:31 -0400 Received: by mail-qk1-f195.google.com with SMTP id s14so5062319qkm.4 for ; Fri, 16 Aug 2019 08:20:31 -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=ldgz5KIxke3jzqUaPc7l5V8q7twuRCp8/4jzuyZ5FYo=; b=D2BMpZR2k3DYlO/2B6h2ahZg3iBwhrgMlUcMD4aOw1Pmea+DKOZ0ZYWoj+vcau/z05 pR+2R8rB6tNhSccmvUDYmNIccV0OIS1Ug3EStMLYo7UQjbeiUoVb5boaoCwWL+rm016a kTRDb/MAR9NdiyBNQ8ePJ3MtZteE4M7wT3q9ESyT4MJFVSHDovESrkBCjlxL18QOumKK HSlO1DpUKMjK9NdcF1v8ESwHRlHM9zjP8f2bt/xUMgQLnLQ8EDVrztcmEWCp6Pl9CKPD w8lXGEn+epyYzUC6A+UWOPh4HHLUEw04y42AH9dBDDLA0oBk5PXZEdNBlFxHKepcrXVh eZyw== 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=ldgz5KIxke3jzqUaPc7l5V8q7twuRCp8/4jzuyZ5FYo=; b=Gb8s+qlOgJ5CoUG3BcMrXPbKVIImOxWB04IYOrFqyVGB3T2jYiaUKRfjYmBfkFi90y fDcUrtHnRd99j7mQ055+veHe5L0qj7KSihgoWqTU+NLiid0v7DASFlMJFbdVCsWJWJPg 6AYJ4bkrRjUgVsF7HGYUSDDyWgoYepXyOq/HC7L+UvAfZ8/NJ7PVhlkJW+ZARcrwnxSS ydw9kyhER/BuScObQ1U1VArQMlNg/MsGS2M/E2I3c1vQG0bY0TwyVuxTArUhh2TmRA5g BgJ9jiMv8F6CFmvubJGimrRDoQ69aGATEFXX80WjHQbFUtRv47d0Y5PZzmCWw0EfbSJs qiiQ== X-Gm-Message-State: APjAAAWCl4+eG2u3SktjVsH4DNds0OTBgtNxbNUNi4Ljh4U3WOiOiaKe xYpHu8BBqO3yu27aWHy4qxTiNfc7l0akOQ== X-Google-Smtp-Source: APXvYqz6wfExQmzZo/FtcLgcZdIU+TU9Enw53CxbQqXm2rHY5SbVBYUBH6CZ5VvZqKWn5/ELx6Pc9A== X-Received: by 2002:a37:717:: with SMTP id 23mr9152401qkh.267.1565968830629; Fri, 16 Aug 2019 08:20:30 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id w10sm2969643qts.37.2019.08.16.08.20.29 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 16 Aug 2019 08:20:30 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 5/5] btrfs: add enospc debug messages for ticket failure Date: Fri, 16 Aug 2019 11:20:19 -0400 Message-Id: <20190816152019.1962-6-josef@toxicpanda.com> X-Mailer: git-send-email 2.21.0 In-Reply-To: <20190816152019.1962-1-josef@toxicpanda.com> References: <20190816152019.1962-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 X-Virus-Scanned: ClamAV using ClamSMTP 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, 24 insertions(+), 8 deletions(-) diff --git a/fs/btrfs/space-info.c b/fs/btrfs/space-info.c index 3d3f301bae26..2819fa91c4f0 100644 --- a/fs/btrfs/space-info.c +++ b/fs/btrfs/space-info.c @@ -256,14 +256,9 @@ 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; - - 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), @@ -273,7 +268,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); @@ -281,6 +275,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; @@ -685,6 +692,11 @@ static bool wake_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, @@ -705,6 +717,10 @@ static bool wake_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);