From patchwork Thu Jul 19 14:50:00 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Josef Bacik X-Patchwork-Id: 10534693 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 C1865600D0 for ; Thu, 19 Jul 2018 14:50:33 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id C802C29CB7 for ; Thu, 19 Jul 2018 14:50:33 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id BC66829CC7; Thu, 19 Jul 2018 14:50: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.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 5F5AC29CB7 for ; Thu, 19 Jul 2018 14:50:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732030AbeGSPeC (ORCPT ); Thu, 19 Jul 2018 11:34:02 -0400 Received: from mail-qt0-f194.google.com ([209.85.216.194]:46748 "EHLO mail-qt0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731993AbeGSPeB (ORCPT ); Thu, 19 Jul 2018 11:34:01 -0400 Received: by mail-qt0-f194.google.com with SMTP id d4-v6so7395062qtn.13 for ; Thu, 19 Jul 2018 07:50:30 -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=cgoK/zOQgfoI+BGicybV2j6y5H01i51qzEaKNGqhTwA=; b=L7L4tgNVm/wXExwFuiNAD9+iTYp0zUrgBBBSFqtrCSPauEL8/srwFxvzpq7/5FS1hz iMCzg9VPWYSTrefE153/ktLEoenVhz+GeLr12P4YQj05qE9C2CE5BNDpeaAJckHeADj9 hBlaqKjg4VH9aEQ8lChYI0fMjEx6gaUw2doB7gJ76L5sx1CoAu5m/aHhFAOdUWcjJVlK B9lKU3/OiD7kB3riB8L2pgMqhJSNwZsKyKKV1BSJnHFIyyfMYbI313+sx9qJOSXAh7fm ubvOUnS+4TmilvVCdRuveEJDHJV0MgdqopIvyCr7/GCy7EhOddUWtBB2DVgEonut3Aip MwzQ== 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=cgoK/zOQgfoI+BGicybV2j6y5H01i51qzEaKNGqhTwA=; b=fr559X7XtZTPIR9gc8mIg4HzWm1eo0oqeytVEWeQH3Cb240HldkhZ6sWSltjX/hdX4 425oWzZcO82k6vHV53MDWBmpxHzuxsONFicwAafnEgd16N50H5CWNjXgOvN+xrGEg2ll yHzrTsE/oMEnYCcTFjw0rQgQWKFQqrU3lW4nMbE6YCYhPDhlFPULJtmZfnOZGClUFtyE Cm4L0kV3XPEpJwdtFrzz0jAyVC7w8rGvSrFOXYqRQ2xGHi1UambTE3bl3sCNyHkNFqq8 Lr1YtIoduBWT7etMMgllDokzwCQrNRYb2+QwKPeQh2dOP92ha1AgoEuOLWF2DNxTZBnJ pDIg== X-Gm-Message-State: AOUpUlHbqs0EboEaTkOytW7TqE9zfM9oejp40BDT2AoLPvu3JLlJ4F8i xH0ljTG1nM55NckRziH4U1dZ7XN+pcE= X-Google-Smtp-Source: AAOMgpfA1jZrwh4zGvsHD9h+aCU35cdpB7eI4DP0nhtmEnUjNoaOgAnVmXPCLVPPnCzy14QVvzzvFA== X-Received: by 2002:ac8:230b:: with SMTP id a11-v6mr10285805qta.123.1532011829546; Thu, 19 Jul 2018 07:50:29 -0700 (PDT) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id k190-v6sm3345479qkd.27.2018.07.19.07.50.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 19 Jul 2018 07:50:29 -0700 (PDT) From: Josef Bacik To: linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 16/22] btrfs: loop in inode_rsv_refill Date: Thu, 19 Jul 2018 10:50:00 -0400 Message-Id: <20180719145006.17532-16-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 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 81396bac53f1..66b28b29839b 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -5860,10 +5860,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; @@ -5888,8 +5889,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; }