From patchwork Fri Oct 28 02:32:54 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: robbieko X-Patchwork-Id: 9400921 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 C95C560588 for ; Fri, 28 Oct 2016 02:33:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id B91652A0E3 for ; Fri, 28 Oct 2016 02:33:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id AD1E12A130; Fri, 28 Oct 2016 02:33:31 +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 E7EDB2A0E3 for ; Fri, 28 Oct 2016 02:33:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1034420AbcJ1Cd0 (ORCPT ); Thu, 27 Oct 2016 22:33:26 -0400 Received: from synology.com ([59.124.61.242]:43533 "EHLO synology.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1034416AbcJ1CdZ (ORCPT ); Thu, 27 Oct 2016 22:33:25 -0400 Received: from localhost.localdomain (unknown [10.12.12.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: robbieko@synology.com) by synology.com (Postfix) with ESMTPSA id 9875B132B07F8; Fri, 28 Oct 2016 10:33:08 +0800 (CST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=synology.com; s=123; t=1477621988; bh=GJbjVmcLHwxOypCEg6/eywbAXxwOun55WEplSIg5vmg=; h=From:To:Cc:Subject:Date; b=XIEP8Y/qFxr5UGSHrn2CMsECck3GdHBv5dd8BskJo9cmBsB2fLAfgt1JtA4LaYwH7 Xn/fzFfZzr5s0DHLg1tKbXjPJEZJ0MNSDxlfrGXbyRTgpLKo4Mncuc2VflchVQejbz TsPaZW0LprwvFc5BzQVOqfh2cgTaDrzzNEkSKeCY= From: robbieko To: linux-btrfs@vger.kernel.org Cc: Robbie Ko Subject: [PATCH v2] Btrfs: fix enospc in hole punching Date: Fri, 28 Oct 2016 10:32:54 +0800 Message-Id: <1477621974-1103-1-git-send-email-robbieko@synology.com> X-Mailer: git-send-email 1.9.1 X-MailScanner-ID: 9875B132B07F8.A5540 X-MailScanner: Found to be clean X-MailScanner-MCPCheck: MCP-Clean, MCP-Checker (score=0, required 80) X-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (not cached, score=-1.39, required 4.5, ALL_TRUSTED -1.00, BAYES_05 -0.50, DKIM_SIGNED 0.10, T_DKIM_INVALID 0.01) X-MailScanner-From: robbieko@synology.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 From: Robbie Ko The hole punching can result in adding new leafs (and as a consequence new nodes) to the tree because when we find file extent items that span beyond the hole range we may end up not deleting them (just adjusting them) and add new file extent items representing holes. That after splitting a leaf (therefore creating a new one), a new node might be added to each level of the tree (since there's a new key and every parent node was full). Fix this by use btrfs_calc_trans_metadata_size instead of btrfs_calc_trunc_metadata_size. v2: * Improve the change log Signed-off-by: Robbie Ko --- fs/btrfs/file.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/btrfs/file.c b/fs/btrfs/file.c index fea31a4..809ca85 100644 --- a/fs/btrfs/file.c +++ b/fs/btrfs/file.c @@ -2322,7 +2322,7 @@ static int btrfs_punch_hole(struct inode *inode, loff_t offset, loff_t len) u64 tail_len; u64 orig_start = offset; u64 cur_offset; - u64 min_size = btrfs_calc_trunc_metadata_size(root, 1); + u64 min_size = btrfs_calc_trans_metadata_size(root, 1); u64 drop_end; int ret = 0; int err = 0; @@ -2469,7 +2469,7 @@ static int btrfs_punch_hole(struct inode *inode, loff_t offset, loff_t len) ret = -ENOMEM; goto out_free; } - rsv->size = btrfs_calc_trunc_metadata_size(root, 1); + rsv->size = btrfs_calc_trans_metadata_size(root, 1); rsv->failfast = 1; /*