From patchwork Fri Jul 7 05:59:27 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 9829593 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 79A7560317 for ; Fri, 7 Jul 2017 05:59:39 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 64BF8285A0 for ; Fri, 7 Jul 2017 05:59:39 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 56B3F285AD; Fri, 7 Jul 2017 05:59:39 +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=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, 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 C33D6285A0 for ; Fri, 7 Jul 2017 05:59:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752341AbdGGF7g (ORCPT ); Fri, 7 Jul 2017 01:59:36 -0400 Received: from mail-pf0-f182.google.com ([209.85.192.182]:34733 "EHLO mail-pf0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750855AbdGGF7f (ORCPT ); Fri, 7 Jul 2017 01:59:35 -0400 Received: by mail-pf0-f182.google.com with SMTP id q85so12019757pfq.1 for ; Thu, 06 Jul 2017 22:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=osandov-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id; bh=pFMvHUxXHgBFYJYTOthRQUFhsEyFJeOCuHpt9XxwbfM=; b=Dc62ozTIsINeyTdKkGTVfPGthCNFa/c1Tyxw5p3NUqcLbOiULnv9yPqm4PMQKHJZ73 KvNysdZHPot3OJgbsRFjOlg3EXGUIa+EopTWtiFI+tWvgIxuutaH748fAM/3YkBRCWHE NLJeq2Wj2KuYUEyQe0uvqCKYdsFdQn16odLeTMp3Q8h+T2eZEHxMGbh4oSCIRfVwjgbO B0VexZNAOCuyu3oe1kKfTDtSOZf9/JU+F4iyVpf59+UhEP1LUbyd2KeTDp2ZLJpaDkI0 DExh7QWsRACnk3jVTcL7ITjCukxal9VE0MIVPlGxfK1i2cGFytoFm3m5j388LjtRZUXw et1g== 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; bh=pFMvHUxXHgBFYJYTOthRQUFhsEyFJeOCuHpt9XxwbfM=; b=QXh9q8Cug/rXTr+8euh28m/GOkDFx7ulH+TY+Flb1bh2zbcJTGEWKtchrWgR7gb1mF w32O7h6C/tUc6zXSF0PaNlq95ebAz9RGsIufxJxlr6gFyqpsSj+EsPPSRuZi5pAP83v9 EW5Szb/xC4KVbA5QR5e416vIizRXALzlXG+ESJ8JiW8yuTY0nx7YwIbxDNuDtOcGo5Gy o6XxckY02VU5sECMApxivTunDm7RB0dk83Zk5GFp81GGrFmA5UwvYfE5kxWZ2X2bBmXN 8CqxdsIujuJropF6+W+fgWydsHnJPhmTWjE93q2/5RStQijqNw7HW0p1OY+rbCf3HUpr ikuw== X-Gm-Message-State: AIVw112enItDi6DSZdDnQjXtOR8YjruYWMESDegu8ncYBiMACGjCqhAf jxNbuu2iYtsf4DTZ1e5pNQ== X-Received: by 10.99.131.193 with SMTP id h184mr30477706pge.80.1499407174552; Thu, 06 Jul 2017 22:59:34 -0700 (PDT) Received: from localhost.localdomain ([2601:602:8801:8110:e6a7:a0ff:fe0b:c9a8]) by smtp.gmail.com with ESMTPSA id d1sm4286582pfj.51.2017.07.06.22.59.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 06 Jul 2017 22:59:34 -0700 (PDT) From: Omar Sandoval To: linux-btrfs@vger.kernel.org Cc: kernel-team@fb.com Subject: [PATCH] Btrfs: fix early ENOSPC due to delalloc Date: Thu, 6 Jul 2017 22:59:27 -0700 Message-Id: <0cf8577381f6ebe99b584ca60f920c630000c343.1499407060.git.osandov@fb.com> X-Mailer: git-send-email 2.13.2 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 From: Omar Sandoval If a lot of metadata is reserved for outstanding delayed allocations, we rely on shrink_delalloc() to reclaim metadata space in order to fulfill reservation tickets. However, shrink_delalloc() has a shortcut where if it determines that space can be overcommitted, it will stop early. This made sense before the ticketed enospc system, but now it means that shrink_delalloc() will often not reclaim enough space to fulfill any tickets, leading to an early ENOSPC. (Reservation tickets don't care about being able to overcommit, they need every byte accounted for.) Fix it by getting rid of the shortcut so that shrink_delalloc() reclaims all of the metadata it is supposed to. This fixes early ENOSPCs we were seeing when doing a btrfs receive to populate a new filesystem. Signed-off-by: Omar Sandoval --- I don't have a good reproducer for this except for the btrfs send stream I was given by someone internally, unfortunately. fs/btrfs/extent-tree.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c index 33d979e9ea2a..83eecd33ad96 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4776,10 +4776,6 @@ static void shrink_delalloc(struct btrfs_root *root, u64 to_reclaim, u64 orig, else flush = BTRFS_RESERVE_NO_FLUSH; spin_lock(&space_info->lock); - if (can_overcommit(root, space_info, orig, flush)) { - spin_unlock(&space_info->lock); - break; - } if (list_empty(&space_info->tickets) && list_empty(&space_info->priority_tickets)) { spin_unlock(&space_info->lock);