From patchwork Thu Jul 19 14:49:56 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 10534687 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 20FBC601D2 for ; Thu, 19 Jul 2018 14:50:27 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 28CBB29CB7 for ; Thu, 19 Jul 2018 14:50:27 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1D7FD29CC6; Thu, 19 Jul 2018 14:50:27 +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.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI, T_DKIM_INVALID 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 BAE3929CB7 for ; Thu, 19 Jul 2018 14:50:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731980AbeGSPd4 (ORCPT ); Thu, 19 Jul 2018 11:33:56 -0400 Received: from mail-qt0-f193.google.com ([209.85.216.193]:40968 "EHLO mail-qt0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731656AbeGSPd4 (ORCPT ); Thu, 19 Jul 2018 11:33:56 -0400 Received: by mail-qt0-f193.google.com with SMTP id e19-v6so7401727qtp.8 for ; Thu, 19 Jul 2018 07:50: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; bh=c9VMKtDHcrbhnpK1jX92pnnHLSzW5uJbj1g7gI34uG0=; b=G3LyHi25hC+NWqdWDSU/LogiFJcKsknP5BbKQQ2CPTVZ1xGLC1rNjoUwo/osj8Ozd3 cXoCPgDmSvl3BWWZsQli9paEh3ueNmBbAs+OJjT0lE16CH8CLATxBjj/dhRV2OJJ0Xb9 Jrsy4PExq5wCHdXLIqGT6nuhuVGFH8dcqCqqgMhGW9FEzR+8oAqA4s6vGoeZIeZo+Oi8 kpFRppWZuytbaMKkCHxhu1/+i+LS1Fx0CWiIPdQwWtC2B40WVchGy240ERWwvNiYNswt 0jrolbNXMLfYvTvRkdBSvhu5SsJg5DeCujy47iNbolCeuuplTK2Un8nZ8RUw1hSNd0KL 3Z9A== 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; bh=c9VMKtDHcrbhnpK1jX92pnnHLSzW5uJbj1g7gI34uG0=; b=oCGkjO83thOteyK0t+penBkyQgFUTIU9MsfSLu5esPBozdUroCS+0s6zfivm+4Py99 BLeT9KrqkjQPAJ4mkFA8IwnxOhBdAO028oA5OagAlrdg8b8bdfEbgyIzW3ge2E/G9WMp NKburgMo4S8i8zQwh1I0FPAYk0E9xq15cE2U+Kfgweyp1sojzhz7d3GV5odVlS6C2T0O BS4scwgztavvU8Jx0+PrdS3ljSvdI2WuE2cRCY7wiE7eB5wR6xf74lM/zJZMNS0z4Zly mVcYlY9HNeQTUXL5pLxEBk08jeVyyxMHn+wLqsPDXmK344tfsVnyHtJz0gVRTw7td8sq /9yg== X-Gm-Message-State: AOUpUlGsdR6RSRt6oGxtamW3MeqFn2xIYrrTMo2MOpfaFEio8hcTC0wA gcGzb6OnvZaDF4/a7xRWGEMSpZeDnsU= X-Google-Smtp-Source: AAOMgpfivldAwlx9+4fvQbK8aJf7dQ6IvEWc9ZKIhoHqDr8fPttR/xcMKl9nEVo6q2CfW8uMqMEKBg== X-Received: by 2002:ac8:13c3:: with SMTP id i3-v6mr9955533qtj.54.1532011824251; Thu, 19 Jul 2018 07:50:24 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id w79-v6sm6149281qkw.35.2018.07.19.07.50.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 19 Jul 2018 07:50:23 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 12/22] btrfs: don't use global rsv for chunk allocation Date: Thu, 19 Jul 2018 10:49:56 -0400 Message-Id: <20180719145006.17532-12-josef@toxicpanda.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180719145006.17532-1-josef@toxicpanda.com> References: <20180719145006.17532-1-josef@toxicpanda.com> 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've done this forever because of the voodoo around knowing how much space we have. However we have better ways of doing this now, and on normal file systems we'll easily have a global reserve of 512MiB, and since metadata chunks are usually 1GiB that means we'll allocate metadata chunks more readily. Instead use the actual used amount when determining if we need to allocate a chunk or not. Signed-off-by: Josef Bacik --- fs/btrfs/extent-tree.c | 9 --------- 1 file changed, 9 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 35c1c1b7ba1d..c20675c265c5 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4459,21 +4459,12 @@ static inline u64 calc_global_rsv_need_space(struct btrfs_block_rsv *global) static int should_alloc_chunk(struct btrfs_fs_info *fs_info, struct btrfs_space_info *sinfo, int force) { - struct btrfs_block_rsv *global_rsv = &fs_info->global_block_rsv; u64 bytes_used = btrfs_space_info_used(sinfo, false); u64 thresh; if (force == CHUNK_ALLOC_FORCE) return 1; - /* - * We need to take into account the global rsv because for all intents - * and purposes it's used space. Don't worry about locking the - * global_rsv, it doesn't change except when the transaction commits. - */ - if (sinfo->flags & BTRFS_BLOCK_GROUP_METADATA) - bytes_used += calc_global_rsv_need_space(global_rsv); - /* * in limited mode, we want to have some free space up to * about 1% of the FS size.