From patchwork Thu Jul 20 22:10:35 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Omar Sandoval X-Patchwork-Id: 9855761 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 1D11860392 for ; Thu, 20 Jul 2017 22:10:48 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0DFE4286E1 for ; Thu, 20 Jul 2017 22:10:48 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 02C2B286F7; Thu, 20 Jul 2017 22:10:47 +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.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, 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 8CE44286E1 for ; Thu, 20 Jul 2017 22:10:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965487AbdGTWKp (ORCPT ); Thu, 20 Jul 2017 18:10:45 -0400 Received: from mail-pg0-f41.google.com ([74.125.83.41]:33945 "EHLO mail-pg0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965416AbdGTWKn (ORCPT ); Thu, 20 Jul 2017 18:10:43 -0400 Received: by mail-pg0-f41.google.com with SMTP id 123so20254443pgj.1 for ; Thu, 20 Jul 2017 15:10:43 -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=B2CbUSCNRsR5+IYICI5KWLUekIPwunis3OlGhDaMnNs=; b=MVLRe7lBoaDe497OnytwdAv7F9QAI7rkGRzWSq88gVhN97JZZ6cQzp6iqNobsnhGzi 9045HY3ck40AuwRuXBxRQrbsbGXxa57XGGaiVR8pFYPSnNHeQIRrBLh5dxt9s9QBngw2 HXbKhXem+qED6xH4Rwc4zWTQEB1nqZ6vfzbvZchoG/FXjy671GtYhLsIFPxIY08liBEy 2wU2pu1LeeJHCV+JZjLfWaOVqR5jvRSaVycdnWuY3tnfl9vS0HN46+w+z29RIeosmSNE gqx1sWtw7teC0RcnWeCD1R7siNh/BZVycnzFkFTuHl8PHh7LulC2KSXYjKYssKgKKcNE 2Vfw== 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=B2CbUSCNRsR5+IYICI5KWLUekIPwunis3OlGhDaMnNs=; b=UxKT5kwPopPsx48SOODcREcNY1e/4nGmlsvloLm9E1gbxxobZVdkanWOPBUyXmTnJY x7ZdrrgCDx2weFp83VM3VFDVZnVZ0Q/O4OFDONaE09YZKmr8MFay05Ue/8eFTEHTXRWE dts43Jl3VaubSExIyDTu0CPKt0xRFZGhdSG7EVARUMy2qGq0wGAg7eO8OZC16LaXjNcs l3qtxvfdYDw9hj/DCaWTnbZUCA3PSAlYEmAPOiOTPfmGa7/EnIi6zJlWZZWrzzRmuucf +/uj4ELhIjR4PwfQ2AInJeyvAEODtQAKQyG3e/6E8JeSBOYLxmAUV1RqzZ2U0Db4LLlJ fxgA== X-Gm-Message-State: AIVw1108N1nIZpmqU8ZPkUKGkUmkIHeyY+Y0VA9G/Z+rAE7664VWcgJ2 J4bWrxeGiFAEqq0pwQlNWA== X-Received: by 10.99.110.7 with SMTP id j7mr5219584pgc.169.1500588642901; Thu, 20 Jul 2017 15:10:42 -0700 (PDT) Received: from vader.thefacebook.com ([2620:10d:c090:200::5:f89b]) by smtp.gmail.com with ESMTPSA id v128sm5371032pgv.49.2017.07.20.15.10.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 20 Jul 2017 15:10:42 -0700 (PDT) From: Omar Sandoval To: linux-btrfs@vger.kernel.org, David Sterba Cc: Christoph Anton Mitterer , Nikolay Borisov , kernel-team@fb.com, stable@vger.kernel.org Subject: [PATCH RESEND] Btrfs: fix early ENOSPC due to delalloc Date: Thu, 20 Jul 2017 15:10:35 -0700 Message-Id: <33ac56aa74691de6109709168939cfe9f56cbd70.1500588286.git.osandov@fb.com> X-Mailer: git-send-email 2.13.3 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, as well as early ENOSPCs Christoph saw when doing a big cp -r onto Btrfs. Fixes: 957780eb2788 ("Btrfs: introduce ticketed enospc infrastructure") Tested-by: Christoph Anton Mitterer Cc: stable@vger.kernel.org Signed-off-by: Omar Sandoval Reviewed-by: Josef Bacik --- Resending with the fixes tag, Cc: stable, Christoph's tested-by, and some info about how Christoph hit the same issue. Nikolay also said it helped slightly with some of his ENOSPC problems. Based on v4.13-rc1. Can we get this in 4.13 and applied to stable? 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 375f8c728d91..5ef0cf399667 100644 --- a/fs/btrfs/extent-tree.c +++ b/fs/btrfs/extent-tree.c @@ -4825,10 +4825,6 @@ static void shrink_delalloc(struct btrfs_fs_info *fs_info, u64 to_reclaim, else flush = BTRFS_RESERVE_NO_FLUSH; spin_lock(&space_info->lock); - if (can_overcommit(fs_info, space_info, orig, flush, false)) { - spin_unlock(&space_info->lock); - break; - } if (list_empty(&space_info->tickets) && list_empty(&space_info->priority_tickets)) { spin_unlock(&space_info->lock);