From patchwork Sat Nov 3 17:15:24 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Amir Goldstein X-Patchwork-Id: 10666723 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 E502114BD for ; Sat, 3 Nov 2018 17:15:40 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id D3E782A060 for ; Sat, 3 Nov 2018 17:15:40 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id C757A2A078; Sat, 3 Nov 2018 17:15:40 +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=-8.0 required=2.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 749AE2A070 for ; Sat, 3 Nov 2018 17:15:39 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727162AbeKDC13 (ORCPT ); Sat, 3 Nov 2018 22:27:29 -0400 Received: from mail-wr1-f66.google.com ([209.85.221.66]:33841 "EHLO mail-wr1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727100AbeKDC13 (ORCPT ); Sat, 3 Nov 2018 22:27:29 -0400 Received: by mail-wr1-f66.google.com with SMTP id j26-v6so5062129wre.1; Sat, 03 Nov 2018 10:15:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=N06V8JClWVZrTNbplS8mhv4SLLZXky8+ybv4IXXergI=; b=JLZDF6TqFpVsNgANSry23oTIQIJ7wmrI5eVhJS1ebIHjIWd/+oylXuD5+QBB55muUD uEM/nSLMmJNG2xoeUrCI15+swruQre3qMaDBWHM5/6Y8RMc5tAi2L8WV6bDOhAhLgclW 3QxDu2E6qsbPDTPVpofjpn9e6BbZyeFXHkXyiOIQ+iV68WOrFPH4jhiqGzB98/9ksqcF /UoWfiNj38bdtM47cxdLE0GreRK4uA/NaEpY9GFtT6taF13xJXWGJrzIW82LjWL57ZoH K7wBn7LQI8YU2dr7ySLH399nwGIuGIcKKJXxQzejWg2XGBqQEbPp47CAkk99aMrCRr8W ir8g== 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=N06V8JClWVZrTNbplS8mhv4SLLZXky8+ybv4IXXergI=; b=S5PyyzOkxuNs40RczNBI8uHzjdx/5uQM/iCoaCUpAnW+sUeJPIALB3U9b142hWABHB cS8kDZOw0p+KEBjkA7JG+U6cfhfAI3MWjTYwO2DznRSykM+bKH3Fj+GpEv/FxFoDglD7 HOLCxFMqkgbKL4AVfPiIl3+06v0NnQBnlf2nNjNDWHs2Akvj8eTZ/DDrcy7Cs4oM+b6H IYmt3rlLQSQJoKaZoITXYx+UboxrTawBnVefFGqH4u32jLUCreqBqIVB/0NGRA3bCpVQ OaUFoIk2BlSSoHoOMnODLEJpKVct1jPr/+eEg6KCIWLEGa+efgmdQ8ZyaVQ22FgMWiQU jDSg== X-Gm-Message-State: AGRZ1gLRK6FyKOBjSiZ9Wf4kTsukIldrS2zK78wt31qyfIbLoLua2JD4 CXPzc0TFb154erfKQa4d0e4= X-Google-Smtp-Source: AJdET5c3kgaej58wJGHYfOJ0N4SXMxf5Y+LA2XAYsX0JrDVwlWl36/c8dXzy/l69x+wBnt+Y8dJccg== X-Received: by 2002:adf:9bd6:: with SMTP id e22-v6mr2740535wrc.295.1541265336208; Sat, 03 Nov 2018 10:15:36 -0700 (PDT) Received: from localhost.localdomain ([5.102.239.131]) by smtp.gmail.com with ESMTPSA id q2sm10495156wrx.77.2018.11.03.10.15.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Nov 2018 10:15:35 -0700 (PDT) From: Amir Goldstein To: "Darrick J . Wong" , Dave Chinner Cc: Eryu Guan , Greg Kroah-Hartman , stable@vger.kernel.org, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, Brian Foster Subject: [PATCH] xfs: truncate transaction does not modify the inobt Date: Sat, 3 Nov 2018 19:15:24 +0200 Message-Id: <20181103171524.2740-1-amir73il@gmail.com> X-Mailer: git-send-email 2.17.1 Sender: linux-xfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Brian Foster The truncate transaction does not ever modify the inode btree, but includes an associated log reservation. Update xfs_calc_itruncate_reservation() to remove the reservation associated with inobt updates. [Amir: This commit was merged for kernel v4.16 and a twin commit was merged for xfsprogs v4.16. As a result, a small xfs filesystem formatted with features -m rmapbt=1,reflink=1 using mkfs.xfs version >= v4.16 cannot be mounted with kernel < v4.16. For example, xfstests generic/17{1,2,3} format a small fs and when trying to mount it, they fail with an assert on this very demonic line: XFS (vdc): Log size 3075 blocks too small, minimum size is 3717 blocks XFS (vdc): AAIEEE! Log failed size checks. Abort! XFS: Assertion failed: 0, file: src/linux/fs/xfs/xfs_log.c, line: 666 The simple solution for stable kernels is to apply this patch, because mkfs.xfs v4.16 is already in the wild, so we have to assume that xfs filesystems with a "too small" log exist. Regardless, xfsprogs maintainers should also consider reverting the twin patch to stop creating those filesystems for the sake of users with unpatched kernels.] Signed-off-by: Brian Foster Reviewed-by: Dave Chinner Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Cc: # v4.9+ Signed-off-by: Amir Goldstein --- Darrick/Dave, It took me a while to figure out what was going on with my test systems when small test partitions (10G) stopped working with older kernels. Please bless this change for stable and consider the remedie for mkfs.xfs I verified that patch cleanly applies to stable kernels 4.14.y and 4.9.y and that I can mount a filsystem created with new mkfs.xfs. I am now running quick tests on stable 4.14.y with configs 4k, 1k, reflink,reflink+overlay to verify no regressions from this patch. Thanks, Amir. fs/xfs/libxfs/xfs_trans_resv.c | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-) diff --git a/fs/xfs/libxfs/xfs_trans_resv.c b/fs/xfs/libxfs/xfs_trans_resv.c index 6bd916bd35e2..48eff18c5496 100644 --- a/fs/xfs/libxfs/xfs_trans_resv.c +++ b/fs/xfs/libxfs/xfs_trans_resv.c @@ -232,8 +232,6 @@ xfs_calc_write_reservation( * the super block to reflect the freed blocks: sector size * worst case split in allocation btrees per extent assuming 4 extents: * 4 exts * 2 trees * (2 * max depth - 1) * block size - * the inode btree: max depth * blocksize - * the allocation btrees: 2 trees * (max depth - 1) * block size */ STATIC uint xfs_calc_itruncate_reservation( @@ -245,12 +243,7 @@ xfs_calc_itruncate_reservation( XFS_FSB_TO_B(mp, 1))), (xfs_calc_buf_res(9, mp->m_sb.sb_sectsize) + xfs_calc_buf_res(xfs_allocfree_log_count(mp, 4), - XFS_FSB_TO_B(mp, 1)) + - xfs_calc_buf_res(5, 0) + - xfs_calc_buf_res(xfs_allocfree_log_count(mp, 1), - XFS_FSB_TO_B(mp, 1)) + - xfs_calc_buf_res(2 + mp->m_ialloc_blks + - mp->m_in_maxlevels, 0))); + XFS_FSB_TO_B(mp, 1)))); } /*