From patchwork Tue Sep 11 17:57:48 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 10596085 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 F3B9914BD for ; Tue, 11 Sep 2018 17:58:44 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id DEEE029B9D for ; Tue, 11 Sep 2018 17:58:44 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D36BD29BA0; Tue, 11 Sep 2018 17:58:44 +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 7AF0729B9D for ; Tue, 11 Sep 2018 17:58:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728305AbeIKW7I (ORCPT ); Tue, 11 Sep 2018 18:59:08 -0400 Received: from mail-qk1-f195.google.com ([209.85.222.195]:41016 "EHLO mail-qk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728184AbeIKW7I (ORCPT ); Tue, 11 Sep 2018 18:59:08 -0400 Received: by mail-qk1-f195.google.com with SMTP id h138-v6so17323795qke.8 for ; Tue, 11 Sep 2018 10:58:42 -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=i5PEGZtGQ9UJCd4gTk8RtE76BvVHV+XTei+gOpQOFls=; b=osO4dpu2nxoEgX6B7B69ROp0Rz1QxtaGOe50E8XkudVd2rnEaxSUHuIRzANZTMBruM l91jdcI3SLewYeDfN0i2YnDv+cINDgqh0NrqF9YulYVhXr0QamYNgA5sRREpDU0h1W0H gmOfmsri3W/ZQ6D3IRGjGSx++a+3olloswtRp9uhYe8uUijpzprY2JB81jFgrQOM7myV BNqnmUfyRY6tY7PXEHOjqgUdUP2sKQjvjRRdRiQHjIh1ER4HGUUA7xTK3RndNKaPrD38 XfoefYT1Rq1X6Hzd+stW/qqGC1/aA39mVSCDlHc7u5VnKKNJxGnMr8PaqYFbUX6zLn12 UDeA== 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=i5PEGZtGQ9UJCd4gTk8RtE76BvVHV+XTei+gOpQOFls=; b=JKQACx4tbGTe75sr9Jtm4fmS05LARwYVMakJDWZnt4FXx4qOhjGyRuFZ9om/E+RtF6 OJ56vPCVL/GrvFz9HXoE1ok/GQKTTVCZspwporj/z3tQQLjPxQlKnSZSfDaMozwkKVW3 ysBDDx6bN/WQGVaCV8UgulIOCawoaIjJf8oCuAJuGGzh1rOxWx93ekhOsQ/WVfe6Vq0e /rmxGbqqCQJ4aMgaLPos835YU6XQ0pVX0oXejNgXi65s64iZCIE4+K/EdMwvnZd13z5T HhGq6GPomYjxeQe1a21yX7zPpgZGf5UFH4AwRAI0nfjiE9yznLUr2+EBKsB+obkjEvdL HBkQ== X-Gm-Message-State: APzg51CHmVLOyzzXCWjMDWuLQIDpKnpxGPf85GdgJ+M1gVlOegNToMgc 83u/7ORUz9ScBQsaYAF0X/9Znw== X-Google-Smtp-Source: ANB0VdYCOQLGI5IAxYH7m/6DtNcVoiMq4zynQ9572zREpLhmkBFQIubzXWuHNeqkb7IhBLmgCei67A== X-Received: by 2002:a37:9dd8:: with SMTP id g207-v6mr19229555qke.19.1536688722069; Tue, 11 Sep 2018 10:58:42 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id s35-v6sm12765779qtj.79.2018.09.11.10.58.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 11 Sep 2018 10:58:41 -0700 (PDT) From: Josef Bacik To: kernel-team@fb.com, linux-btrfs@vger.kernel.org Subject: [PATCH 17/36] btrfs: loop in inode_rsv_refill Date: Tue, 11 Sep 2018 13:57:48 -0400 Message-Id: <20180911175807.26181-18-josef@toxicpanda.com> X-Mailer: git-send-email 2.14.3 In-Reply-To: <20180911175807.26181-1-josef@toxicpanda.com> References: <20180911175807.26181-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 With severe fragmentation we can end up with our inode rsv size being huge during writeout, which would cause us to need to make very large metadata reservations. However we may not actually need that much once writeout is complete. So instead try to make our reservation, and if we couldn't make it re-calculate our new reservation size and try again. If our reservation size doesn't change between tries then we know we are actually out of space and can error out. Signed-off-by: Josef Bacik --- fs/btrfs/extent-tree.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 57567d013447..e43834380ce6 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -5790,10 +5790,11 @@ static int btrfs_inode_rsv_refill(struct btrfs_inode *inode, { struct btrfs_root *root = inode->root; struct btrfs_block_rsv *block_rsv = &inode->block_rsv; - u64 num_bytes = 0; + u64 num_bytes = 0, last = 0; u64 qgroup_num_bytes = 0; int ret = -ENOSPC; +again: spin_lock(&block_rsv->lock); if (block_rsv->reserved < block_rsv->size) num_bytes = block_rsv->size - block_rsv->reserved; @@ -5818,8 +5819,22 @@ static int btrfs_inode_rsv_refill(struct btrfs_inode *inode, spin_lock(&block_rsv->lock); block_rsv->qgroup_rsv_reserved += qgroup_num_bytes; spin_unlock(&block_rsv->lock); - } else + } else { btrfs_qgroup_free_meta_prealloc(root, qgroup_num_bytes); + + /* + * If we are fragmented we can end up with a lot of outstanding + * extents which will make our size be much larger than our + * reserved amount. If we happen to try to do a reservation + * here that may result in us trying to do a pretty hefty + * reservation, which we may not need once delalloc flushing + * happens. If this is the case try and do the reserve again. + */ + if (flush == BTRFS_RESERVE_FLUSH_ALL && last != num_bytes) { + last = num_bytes; + goto again; + } + } return ret; }