From patchwork Thu Aug 22 23:59:01 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13774347 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BFB3C187345 for ; Thu, 22 Aug 2024 23:59:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371142; cv=none; b=dvRldN5M5QWg0F1FQgoMmNl5q64SiQJHld917JgY2abwwhO0R/YKElC+W1DoNNBirxVZibGCuBqgd+N7n8ABO2Z1mj/tB+VJpTHu+eWbfu523sacg/j4lV04Z+7PUBumwHrK/MzHSMsGZYT6h1mXUp/MRoSpaJZTDOXhEVMLwJo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371142; c=relaxed/simple; bh=+BQri2zCpb77r8VeZq+Qu9Ub0vgDI8VIZ4sZd0FKb0A=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=G0AemMPjbC+bpO8d6wX4HZ5omtCvNNdwe355MdMIBn5KCO8tIYAYTbggWnpUD7VF6hGqdSb02E90ybr1pNHooWYZ9cinSTrmcZ+lH4vEhttb7//14ycMFOJ5CreQuRkAvwS4zXnQcfkY9OAgn8MlKqTy6LWlt4d3pr9iWAZ9AOw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=JSBiJ9MB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="JSBiJ9MB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4FC65C4AF0B; Thu, 22 Aug 2024 23:59:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724371142; bh=+BQri2zCpb77r8VeZq+Qu9Ub0vgDI8VIZ4sZd0FKb0A=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=JSBiJ9MB+753SOdXPc4sHZwYAe4BdIPOISyvD9sT+utmSIyFZGT2kCYaLWWyobAPi 9MzXEm68LQT/WCpJraHmR2gR2bG9uChCj5Vo08inoCKXaOXEO6G+MOkmzv4G4+x9i4 WMw/rifMvvz2EWHjHI/u54vQZ7SpWDi1Zp8swzCXzTRQNaSGuHkQTOrT1QDvBOU+3P IjyO/9BcKkaGFVfOfrqbE3KEJi/YONAliu6a5sekYJ9CvXNp37qxjOdNVdjomBxJX8 T9MW/2VpjMsVWx9sKmdYJT9ofQztvHNjhEc1ssCMkCSYdNR42tqK9hX4joItMmjlHb bO0lghlfpFp1A== Date: Thu, 22 Aug 2024 16:59:01 -0700 Subject: [PATCH 1/9] xfs: fix di_onlink checking for V1/V2 inodes From: "Darrick J. Wong" To: djwong@kernel.org Cc: kjell.m.randa@gmail.com, Christoph Hellwig , hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <172437083768.56860.15670987236466728044.stgit@frogsfrogsfrogs> In-Reply-To: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> References: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong "KjellR" complained on IRC that an old V4 filesystem suddenly stopped mounting after upgrading from 6.9.11 to 6.10.3, with the following splat when trying to read the rt bitmap inode: 00000000: 49 4e 80 00 01 02 00 01 00 00 00 00 00 00 00 00 IN.............. 00000010: 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000020: 00 00 00 00 00 00 00 00 43 d2 a9 da 21 0f d6 30 ........C...!..0 00000030: 43 d2 a9 da 21 0f d6 30 00 00 00 00 00 00 00 00 C...!..0........ 00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000050: 00 00 00 02 00 00 00 00 00 00 00 04 00 00 00 00 ................ 00000060: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ As Dave Chinner points out, this is a V1 inode with both di_onlink and di_nlink set to 1 and di_flushiter == 0. In other words, this inode was formatted this way by mkfs and hasn't been touched since then. Back in the old days of xfsprogs 3.2.3, I observed that libxfs_ialloc would set di_nlink, but if the filesystem didn't have NLINK, it would then set di_version = 1. libxfs_iflush_int later sees the V1 inode and copies the value of di_nlink to di_onlink without zeroing di_onlink. Eventually this filesystem must have been upgraded to support NLINK because 6.10 doesn't support !NLINK filesystems, which is how we tripped over this old behavior. The filesystem doesn't have a realtime section, so that's why the rtbitmap inode has never been touched. Fix this by removing the di_onlink/di_nlink checking for all V1/V2 inodes because this is a muddy mess. The V3 inode handling code has always supported NLINK and written di_onlink==0 so keep that check. The removal of the V1 inode handling code when we dropped support for !NLINK obscured this old behavior. Reported-by: kjell.m.randa@gmail.com Fixes: 40cb8613d612 ("xfs: check unused nlink fields in the ondisk inode") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- fs/xfs/libxfs/xfs_inode_buf.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/fs/xfs/libxfs/xfs_inode_buf.c b/fs/xfs/libxfs/xfs_inode_buf.c index 513b50da6215f..79babeac9d754 100644 --- a/fs/xfs/libxfs/xfs_inode_buf.c +++ b/fs/xfs/libxfs/xfs_inode_buf.c @@ -514,12 +514,18 @@ xfs_dinode_verify( return __this_address; } - if (dip->di_version > 1) { + /* + * Historical note: xfsprogs in the 3.2 era set up its incore inodes to + * have di_nlink track the link count, even if the actual filesystem + * only supported V1 inodes (i.e. di_onlink). When writing out the + * ondisk inode, it would set both the ondisk di_nlink and di_onlink to + * the the incore di_nlink value, which is why we cannot check for + * di_nlink==0 on a V1 inode. V2/3 inodes would get written out with + * di_onlink==0, so we can check that. + */ + if (dip->di_version >= 2) { if (dip->di_onlink) return __this_address; - } else { - if (dip->di_nlink) - return __this_address; } /* don't allow invalid i_size */ From patchwork Thu Aug 22 23:59:17 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13774348 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F97B17E006 for ; Thu, 22 Aug 2024 23:59:18 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371158; cv=none; b=DdwavGGKylnFsI44sqm3MQVkA7u6+bI3tmQPjCpt3qkIfkME9Ln2akWPrx8cl4yk6HN1Jvv3iRq4tzWuVtjai24chi54wJ/kkgMcOlY/gUlm47btrsRDwwimyfZEmxQr8WM9ae15guqW54aG7bhX5MBAPir3y3GNVv/tiMW7ztg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371158; c=relaxed/simple; bh=5WwgPFYIRHb84m1oEVgwekJWBC0347vAB2EpZAcX8wM=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=J3L10vycNwNgg1hOHGEwhXyW9groLFGA6vzn06xo5kuV2OpacagMEg9htGvhCQvfZiuCK9dke9hshbDQIuKEyvCogFOdUryo9aAJ7GquBb/YGYqycI0D8PoDLJCLq9GHV4f2GMHiZWJcRNhc2hm0GzruhWsrS2gHEuVJIOaS6TY= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=h6PLvlDp; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="h6PLvlDp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E70F3C32782; Thu, 22 Aug 2024 23:59:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724371158; bh=5WwgPFYIRHb84m1oEVgwekJWBC0347vAB2EpZAcX8wM=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=h6PLvlDpqmd8O+hKPEKXBZxeplloIXgxYeQPai/h7Lc3GOtQs3N7AoVYEalDjO5Z8 QVsiesRbBMFmq6Y6zakzVN1gSo/WRvHauVbqGcoavG/pRXEmtivdY4CS6XBADaJeE3 FVdsJ3mN1+vorkpKwfA2A4lF4RYObUdVenKawiUwCAvEV+r3kpPw96f3uW5SxSUacx tkZgKah+ZheBKDwytgArAiOVaAlXszpHJhxpJJ0RULTD1VuvVodOU7k/I+3+udPSZh 3PdA/t+rN4DM5Ux0n+LHRBI0FShmTRmx27IQcXSuINuNx32wGmWltAQVh9ByJsF6eC Gz3UVYNMhOxEQ== Date: Thu, 22 Aug 2024 16:59:17 -0700 Subject: [PATCH 2/9] xfs: fix folio dirtying for XFILE_ALLOC callers From: "Darrick J. Wong" To: djwong@kernel.org Cc: willy@infradead.org, Christoph Hellwig , hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <172437083785.56860.5451255060419862713.stgit@frogsfrogsfrogs> In-Reply-To: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> References: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong willy pointed out that folio_mark_dirty is the correct function to use to mark an xfile folio dirty because it calls out to the mapping's aops to mark it dirty. For tmpfs this likely doesn't matter much since it currently uses nop_dirty_folio, but let's use the abstractions properly. Reported-by: willy@infradead.org Fixes: 6907e3c00a40 ("xfs: add file_{get,put}_folio") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- fs/xfs/scrub/xfile.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/scrub/xfile.c b/fs/xfs/scrub/xfile.c index d848222f802ba..9b5d98fe1f8ab 100644 --- a/fs/xfs/scrub/xfile.c +++ b/fs/xfs/scrub/xfile.c @@ -293,7 +293,7 @@ xfile_get_folio( * (potentially last) reference in xfile_put_folio. */ if (flags & XFILE_ALLOC) - folio_set_dirty(folio); + folio_mark_dirty(folio); return folio; } From patchwork Thu Aug 22 23:59:33 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13774349 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1EE0517E006 for ; Thu, 22 Aug 2024 23:59:33 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371174; cv=none; b=UYlUOlvmXLA5HTdd6sDaQrXjmKLxsbMEdaXooeRyLyAx2xzxDgydn6hVKln/AOQaE7DP0TleYEtCcUViimTflC+/XZAIngyOyale5CoXsjfa2MZn9H17JBDNY7g3qJWTrI2ng2qmpGJQZ6tnj8ZUldZbzvsxOMydiuozfKj6OeU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371174; c=relaxed/simple; bh=OCfNDuvB5PBHF78VLOzk6RbtJTOlHXml9nN6tKC03mw=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=s3wo2/5fG1wziYhvJ9+k/dOLS8YVwNXby48/ved9PqNE9IL73Ag8dtaeKl5CS6EGN0k8LC35ohgYmWpIHuXYG4jjlQ2DDHLWDh45OEFvvm6Ud1Nz/z2dvcxHaPcWbCPV06s8vgd5ez9v1tGeq7vmyjj42hAPPlLPXpiICk53ej8= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ZyfXaFTc; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ZyfXaFTc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8C856C32782; Thu, 22 Aug 2024 23:59:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724371173; bh=OCfNDuvB5PBHF78VLOzk6RbtJTOlHXml9nN6tKC03mw=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=ZyfXaFTcpC44tN4ySqJYSf8v/TaE6Zd1cfw4XmQW31mlob9GiNgjpKOzZKIKkrMh9 0dDLV7zFKwNZvQ3Hl7UUSmVDqnz+ay+s8WHhqnj7AbMq/TH1m8jlNySpvl80A6HeMu rLwhfzvUhRJrhuSjNiWw4vUBZdmhSAYvuZcnGuD/yXaaWRsUZDCwCFW7ZMbTCRivji XYo5fGipQxoWPxcvYzwd1Lo6RNO82VtM3XwNluPPK64uLcm2NZJbLP+IECvqw6auYl emyPMON9KYVaRuYAe+Vg7ocgZ2rne9bCnmYaVnuPHWMw2PQlK9n9ZvPPfbjEcsC67+ fSj4LART21/fA== Date: Thu, 22 Aug 2024 16:59:33 -0700 Subject: [PATCH 3/9] xfs: xfs_finobt_count_blocks() walks the wrong btree From: "Darrick J. Wong" To: djwong@kernel.org Cc: Anders Blomdell , Dave Chinner , Christoph Hellwig , hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <172437083802.56860.3620518618047728107.stgit@frogsfrogsfrogs> In-Reply-To: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> References: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Dave Chinner As a result of the factoring in commit 14dd46cf31f4 ("xfs: split xfs_inobt_init_cursor"), mount started taking a long time on a user's filesystem. For Anders, this made mount times regress from under a second to over 15 minutes for a filesystem with only 30 million inodes in it. Anders bisected it down to the above commit, but even then the bug was not obvious. In this commit, over 20 calls to xfs_inobt_init_cursor() were modified, and some we modified to call a new function named xfs_finobt_init_cursor(). If that takes you a moment to reread those function names to see what the rename was, then you have realised why this bug wasn't spotted during review. And it wasn't spotted on inspection even after the bisect pointed at this commit - a single missing "f" isn't the easiest thing for a human eye to notice.... The result is that xfs_finobt_count_blocks() now incorrectly calls xfs_inobt_init_cursor() so it is now walking the inobt instead of the finobt. Hence when there are lots of allocated inodes in a filesystem, mount takes a -long- time run because it now walks a massive allocated inode btrees instead of the small, nearly empty free inode btrees. It also means all the finobt space reservations are wrong, so mount could potentially given ENOSPC on kernel upgrade. In hindsight, commit 14dd46cf31f4 should have been two commits - the first to convert the finobt callers to the new API, the second to modify the xfs_inobt_init_cursor() API for the inobt callers. That would have made the bug very obvious during review. Fixes: 14dd46cf31f4 ("xfs: split xfs_inobt_init_cursor") Reported-by: Anders Blomdell Signed-off-by: Dave Chinner Reviewed-by: Christoph Hellwig Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong --- fs/xfs/libxfs/xfs_ialloc_btree.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/libxfs/xfs_ialloc_btree.c b/fs/xfs/libxfs/xfs_ialloc_btree.c index 496e2f72a85b9..797d5b5f7b725 100644 --- a/fs/xfs/libxfs/xfs_ialloc_btree.c +++ b/fs/xfs/libxfs/xfs_ialloc_btree.c @@ -749,7 +749,7 @@ xfs_finobt_count_blocks( if (error) return error; - cur = xfs_inobt_init_cursor(pag, tp, agbp); + cur = xfs_finobt_init_cursor(pag, tp, agbp); error = xfs_btree_count_blocks(cur, tree_blocks); xfs_btree_del_cursor(cur, error); xfs_trans_brelse(tp, agbp); From patchwork Thu Aug 22 23:59:48 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13774350 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A665318732C for ; Thu, 22 Aug 2024 23:59:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371189; cv=none; b=f/4MN+H9mnrpDKFxPoWtNBpXxzOWR0JDMMU49sz7Dl84mqUVFvwWRV5K2HvX2jX0xEJbdz+Zy8eE1m6JT7qFl+0NWiMhWaeCXibC01aGuyd57wYWM5hOOc5RmA86M6VaVOpf0Keh4c3/oTK2v4uzlPFBgKxPdsZZ+oa+O+VSnY8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371189; c=relaxed/simple; bh=0quQVLfRgrTxIiQE05bcM8l4Wi+bXiQSK/sWva+K1oQ=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=YPRl2OsFWojSiV0Wn2ALxQZdHOh0EYF60xKLyQdAS/MsCAXBSVZ2jsel4Hql4TThaxhCBKfok4SxUgFaulKbkWDGILNh3MA75qqpvBIyjjfnWAHvhvbUfKB9WQcIb1s8Kla84zyilEqBu2RF7zrnIGSOe5H3W71ulVVCmcKrD+A= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=njmH1HEB; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="njmH1HEB" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3AF74C32782; Thu, 22 Aug 2024 23:59:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724371189; bh=0quQVLfRgrTxIiQE05bcM8l4Wi+bXiQSK/sWva+K1oQ=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=njmH1HEBmRjFsvb5b71m3nyCVBooyKRZ5IwQRf13Uu1ki4A0hFHCAWfp2CjtnyO/P n2Pox7VlP0LBoCtZic6Yd+L5qYKAU34SNO7fb0rwxePTgw4oDGGSYEBXKslKVC27Z5 TYrbSzbnCYRJh85gVnAtW2AcRCcF/tZENFhGRcmT51O20bGsGadzdiYvDFdrf1sJN0 1Bc/Z4b4Xlkse8y5Rd7k0bY8EwC6ll8UJXt4C2RlISPfEJDRFUjIn+JEzkHs+A2Cf+ /akNa6PnebZ66Pwx1nu0QdOynOv43z+lSXjSHLVK5aHtDGOG6Pn6qshMsLYk78C8Sl ulCZoXrMWo/Sw== Date: Thu, 22 Aug 2024 16:59:48 -0700 Subject: [PATCH 4/9] xfs: don't bother reporting blocks trimmed via FITRIM From: "Darrick J. Wong" To: djwong@kernel.org Cc: Christoph Hellwig , Christoph Hellwig , hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <172437083819.56860.1505619846644204416.stgit@frogsfrogsfrogs> In-Reply-To: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> References: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Don't bother reporting the number of bytes that we "trimmed" because the underlying storage isn't required to do anything(!) and failed discard IOs aren't reported to the caller anyway. It's not like userspace can use the reported value for anything useful like adjusting the offset parameter of the next call, and it's not like anyone ever wrote a manpage about FITRIM's out parameters. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig Tested-by: Christoph Hellwig --- fs/xfs/xfs_discard.c | 36 +++++++++++------------------------- 1 file changed, 11 insertions(+), 25 deletions(-) diff --git a/fs/xfs/xfs_discard.c b/fs/xfs/xfs_discard.c index 6f0fc7fe1f2ba..25f5dffeab2ae 100644 --- a/fs/xfs/xfs_discard.c +++ b/fs/xfs/xfs_discard.c @@ -158,8 +158,7 @@ static int xfs_trim_gather_extents( struct xfs_perag *pag, struct xfs_trim_cur *tcur, - struct xfs_busy_extents *extents, - uint64_t *blocks_trimmed) + struct xfs_busy_extents *extents) { struct xfs_mount *mp = pag->pag_mount; struct xfs_trans *tp; @@ -280,7 +279,6 @@ xfs_trim_gather_extents( xfs_extent_busy_insert_discard(pag, fbno, flen, &extents->extent_list); - *blocks_trimmed += flen; next_extent: if (tcur->by_bno) error = xfs_btree_increment(cur, 0, &i); @@ -327,8 +325,7 @@ xfs_trim_perag_extents( struct xfs_perag *pag, xfs_agblock_t start, xfs_agblock_t end, - xfs_extlen_t minlen, - uint64_t *blocks_trimmed) + xfs_extlen_t minlen) { struct xfs_trim_cur tcur = { .start = start, @@ -354,8 +351,7 @@ xfs_trim_perag_extents( extents->owner = extents; INIT_LIST_HEAD(&extents->extent_list); - error = xfs_trim_gather_extents(pag, &tcur, extents, - blocks_trimmed); + error = xfs_trim_gather_extents(pag, &tcur, extents); if (error) { kfree(extents); break; @@ -389,8 +385,7 @@ xfs_trim_datadev_extents( struct xfs_mount *mp, xfs_daddr_t start, xfs_daddr_t end, - xfs_extlen_t minlen, - uint64_t *blocks_trimmed) + xfs_extlen_t minlen) { xfs_agnumber_t start_agno, end_agno; xfs_agblock_t start_agbno, end_agbno; @@ -411,8 +406,7 @@ xfs_trim_datadev_extents( if (start_agno == end_agno) agend = end_agbno; - error = xfs_trim_perag_extents(pag, start_agbno, agend, minlen, - blocks_trimmed); + error = xfs_trim_perag_extents(pag, start_agbno, agend, minlen); if (error) last_error = error; @@ -431,9 +425,6 @@ struct xfs_trim_rtdev { /* list of rt extents to free */ struct list_head extent_list; - /* pointer to count of blocks trimmed */ - uint64_t *blocks_trimmed; - /* minimum length that caller allows us to trim */ xfs_rtblock_t minlen_fsb; @@ -551,7 +542,6 @@ xfs_trim_gather_rtextent( busyp->length = rlen; INIT_LIST_HEAD(&busyp->list); list_add_tail(&busyp->list, &tr->extent_list); - *tr->blocks_trimmed += rlen; tr->restart_rtx = rec->ar_startext + rec->ar_extcount; return 0; @@ -562,13 +552,11 @@ xfs_trim_rtdev_extents( struct xfs_mount *mp, xfs_daddr_t start, xfs_daddr_t end, - xfs_daddr_t minlen, - uint64_t *blocks_trimmed) + xfs_daddr_t minlen) { struct xfs_rtalloc_rec low = { }; struct xfs_rtalloc_rec high = { }; struct xfs_trim_rtdev tr = { - .blocks_trimmed = blocks_trimmed, .minlen_fsb = XFS_BB_TO_FSB(mp, minlen), }; struct xfs_trans *tp; @@ -634,7 +622,7 @@ xfs_trim_rtdev_extents( return error; } #else -# define xfs_trim_rtdev_extents(m,s,e,n,b) (-EOPNOTSUPP) +# define xfs_trim_rtdev_extents(...) (-EOPNOTSUPP) #endif /* CONFIG_XFS_RT */ /* @@ -661,7 +649,6 @@ xfs_ioc_trim( xfs_daddr_t start, end; xfs_extlen_t minlen; xfs_rfsblock_t max_blocks; - uint64_t blocks_trimmed = 0; int error, last_error = 0; if (!capable(CAP_SYS_ADMIN)) @@ -706,15 +693,13 @@ xfs_ioc_trim( end = start + BTOBBT(range.len) - 1; if (bdev_max_discard_sectors(mp->m_ddev_targp->bt_bdev)) { - error = xfs_trim_datadev_extents(mp, start, end, minlen, - &blocks_trimmed); + error = xfs_trim_datadev_extents(mp, start, end, minlen); if (error) last_error = error; } if (rt_bdev && !xfs_trim_should_stop()) { - error = xfs_trim_rtdev_extents(mp, start, end, minlen, - &blocks_trimmed); + error = xfs_trim_rtdev_extents(mp, start, end, minlen); if (error) last_error = error; } @@ -722,7 +707,8 @@ xfs_ioc_trim( if (last_error) return last_error; - range.len = XFS_FSB_TO_B(mp, blocks_trimmed); + range.len = min_t(unsigned long long, range.len, + XFS_FSB_TO_B(mp, max_blocks)); if (copy_to_user(urange, &range, sizeof(range))) return -EFAULT; return 0; From patchwork Fri Aug 23 00:00:04 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13774351 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 234DB17C7DC for ; Fri, 23 Aug 2024 00:00:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371205; cv=none; b=rCMPzEV4+qYLsLzh1Kdp7Xc6836G4r/IjMkYcXEAbtQKJ/8uo8kIQxcflE9VV7wY7Gz8SfhkgrSV8wTJflb8nqxHJptNGP/XecJQmnDR9Jvmxg5KcSvVNmeE6lOc5+GHDOOoJWkU/Wx8p5rHEto5WlOOmdmsBFiUPsRpDRzWEJc= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371205; c=relaxed/simple; bh=01UDe+VY+BY5MAHOTVxF/KaXmZaZFoGjAnUT1iZTN1g=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=JRSnBwkoZkFpDD/av5DM9dhcpPi9Dfq8FYPEBetlbIlLWzxKlkUbESk/Wf5QNoujQt6N6oOjMRDywX9ui5QqMqzr7nLwEwHiTwKlSl/l93nwLQWKfB1ZIW+c2fTnbvtMRFXjAMcI7ggS9Wr121/xB/ybwfv3WsUytNnuDJQSljI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ByOJdoqN; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ByOJdoqN" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E028FC4AF10; Fri, 23 Aug 2024 00:00:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724371204; bh=01UDe+VY+BY5MAHOTVxF/KaXmZaZFoGjAnUT1iZTN1g=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=ByOJdoqN6Ndn3b2v6h03XkQA9wvqfylE43tx4BSDDojkFyAOx7QaqfgKBHhzhzobQ 8aF5s1SXpsa7VY2tBAI2F2gRDI78F8iUQEROufCjoyHy2qX/dDTdgSgrlqdhhl2Z86 Lkr38lgMSBGOCCI9q6wzM0mgGTCl7XBHrh9D0P6RnaRvw84tC8v4DZSBwAwGR46QLO +cj43BK2MtlKi4/uyYnjMu5A5lG14xNd4CmWes9XLtFAc3vusjX2CN+m5Vxyi0Aonh S+ZY4QOl8muSxi0P5yoCi/Qy98530KREPLqAhEq0xFgifUQD8euTd8Ss6k4dzIbaK/ WGthlXBgNdYuQ== Date: Thu, 22 Aug 2024 17:00:04 -0700 Subject: [PATCH 5/9] xfs: Fix the owner setting issue for rmap query in xfs fsmap From: "Darrick J. Wong" To: djwong@kernel.org Cc: Zizhi Wo , hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <172437083836.56860.11859978469978791125.stgit@frogsfrogsfrogs> In-Reply-To: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> References: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Zizhi Wo I notice a rmap query bug in xfs_io fsmap: [root@fedora ~]# xfs_io -c 'fsmap -vvvv' /mnt EXT: DEV BLOCK-RANGE OWNER FILE-OFFSET AG AG-OFFSET TOTAL 0: 253:16 [0..7]: static fs metadata 0 (0..7) 8 1: 253:16 [8..23]: per-AG metadata 0 (8..23) 16 2: 253:16 [24..39]: inode btree 0 (24..39) 16 3: 253:16 [40..47]: per-AG metadata 0 (40..47) 8 4: 253:16 [48..55]: refcount btree 0 (48..55) 8 5: 253:16 [56..103]: per-AG metadata 0 (56..103) 48 6: 253:16 [104..127]: free space 0 (104..127) 24 ...... Bug: [root@fedora ~]# xfs_io -c 'fsmap -vvvv -d 0 3' /mnt [root@fedora ~]# Normally, we should be able to get one record, but we got nothing. The root cause of this problem lies in the incorrect setting of rm_owner in the rmap query. In the case of the initial query where the owner is not set, __xfs_getfsmap_datadev() first sets info->high.rm_owner to ULLONG_MAX. This is done to prevent any omissions when comparing rmap items. However, if the current ag is detected to be the last one, the function sets info's high_irec based on the provided key. If high->rm_owner is not specified, it should continue to be set to ULLONG_MAX; otherwise, there will be issues with interval omissions. For example, consider "start" and "end" within the same block. If high->rm_owner == 0, it will be smaller than the founded record in rmapbt, resulting in a query with no records. The main call stack is as follows: xfs_ioc_getfsmap xfs_getfsmap xfs_getfsmap_datadev_rmapbt __xfs_getfsmap_datadev info->high.rm_owner = ULLONG_MAX if (pag->pag_agno == end_ag) xfs_fsmap_owner_to_rmap // set info->high.rm_owner = 0 because fmr_owner == -1ULL dest->rm_owner = 0 // get nothing xfs_getfsmap_datadev_rmapbt_query The problem can be resolved by simply modify the xfs_fsmap_owner_to_rmap function internal logic to achieve. After applying this patch, the above problem have been solved: [root@fedora ~]# xfs_io -c 'fsmap -vvvv -d 0 3' /mnt EXT: DEV BLOCK-RANGE OWNER FILE-OFFSET AG AG-OFFSET TOTAL 0: 253:16 [0..7]: static fs metadata 0 (0..7) 8 Fixes: e89c041338ed ("xfs: implement the GETFSMAP ioctl") Signed-off-by: Zizhi Wo Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- fs/xfs/xfs_fsmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/xfs/xfs_fsmap.c b/fs/xfs/xfs_fsmap.c index 85dbb46452ca0..3a30b36779db5 100644 --- a/fs/xfs/xfs_fsmap.c +++ b/fs/xfs/xfs_fsmap.c @@ -71,7 +71,7 @@ xfs_fsmap_owner_to_rmap( switch (src->fmr_owner) { case 0: /* "lowest owner id possible" */ case -1ULL: /* "highest owner id possible" */ - dest->rm_owner = 0; + dest->rm_owner = src->fmr_owner; break; case XFS_FMR_OWN_FREE: dest->rm_owner = XFS_RMAP_OWN_NULL; From patchwork Fri Aug 23 00:00:20 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13774352 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 14E7F812 for ; Fri, 23 Aug 2024 00:00:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371221; cv=none; b=XETulYRh27LIYiQzvcY3IufVf5qy3JivEucz1gMXCvt8WM/1WlSpJ/ji79vHzXvOf9Lfw3EjEPbeGjI3us8+/QXwLQ5QDiz8nGsY99ALQXXkCynhIeUpkIYY4jXypfA0HoPSJAGAhJIjFqe9AbOqCwhqlj6Ht4eFdjk9HcqydxA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371221; c=relaxed/simple; bh=lXZId0GxsglspRxrZlW3xgrJimcn76uA6tt0PXNxVEM=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=lQlKky0bnBS/2aN9YinzmGpPcm11V5yWGjK2i+CajpSGM/MlrAK61gdVUTfgpK9/ibCQnf88KNiK3NMdCWDFXqTJ03AJcS39scurCTmmBGRFo34G/6UssYLMrkAhCHYXkcDgVcB5svFoe22rNV3nAww9u1LHBfH6853rJXQOYKQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Y69ngV5b; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Y69ngV5b" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8D457C32782; Fri, 23 Aug 2024 00:00:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724371220; bh=lXZId0GxsglspRxrZlW3xgrJimcn76uA6tt0PXNxVEM=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=Y69ngV5bQ/w4gOH7rLltv2nwy6oIM/BeRKi96xpOOdhIoofOAcB6vUFDLo5V4eqDm Xr7Fg9lm79jtgJfkBueDYA2T1QVmQlDwp7vsTXHJRexG4M3eOJGf6erTupdwqk4Fuh jRSPV4zctpMN/NvMXl7xzDpT5uxWd7pp18KjSL/26aDVYz+0+XAp/Qcm+D4hzrn/1U INynzPJeX26mWNlaD07t4GHxPSrT7jaMroPrwx7f9USwb3qn6T6RHDVlR6mzksF7EX GPB4igin0Cm28d3hCqPEZk7YBd3ckYONUzpot7mOYz3D2LTej7q7Kn/VxXhvOeguIl gGeNPs3mJl1hA== Date: Thu, 22 Aug 2024 17:00:20 -0700 Subject: [PATCH 6/9] xfs: use XFS_BUF_DADDR_NULL for daddrs in getfsmap code From: "Darrick J. Wong" To: djwong@kernel.org Cc: wozizhi@huawei.com, hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <172437083853.56860.15801624695777560515.stgit@frogsfrogsfrogs> In-Reply-To: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> References: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Use XFS_BUF_DADDR_NULL (instead of a magic sentinel value) to mean "this field is null" like the rest of xfs. Cc: wozizhi@huawei.com Fixes: e89c041338ed6 ("xfs: implement the GETFSMAP ioctl") Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- fs/xfs/xfs_fsmap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/xfs/xfs_fsmap.c b/fs/xfs/xfs_fsmap.c index 3a30b36779db5..613a0ec204120 100644 --- a/fs/xfs/xfs_fsmap.c +++ b/fs/xfs/xfs_fsmap.c @@ -252,7 +252,7 @@ xfs_getfsmap_rec_before_start( const struct xfs_rmap_irec *rec, xfs_daddr_t rec_daddr) { - if (info->low_daddr != -1ULL) + if (info->low_daddr != XFS_BUF_DADDR_NULL) return rec_daddr < info->low_daddr; if (info->low.rm_blockcount) return xfs_rmap_compare(rec, &info->low) < 0; @@ -983,7 +983,7 @@ xfs_getfsmap( info.dev = handlers[i].dev; info.last = false; info.pag = NULL; - info.low_daddr = -1ULL; + info.low_daddr = XFS_BUF_DADDR_NULL; info.low.rm_blockcount = 0; error = handlers[i].fn(tp, dkeys, &info); if (error) From patchwork Fri Aug 23 00:00:35 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13774353 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 94B24524B4 for ; Fri, 23 Aug 2024 00:00:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371236; cv=none; b=acIPwhbQV+DUgcfhsGEeqvy6MSyBjVXn8hHbnkc8fOtTtqXtNui563cg50DDwwfCX0FzDnIs7ZgAj0617WxxqG3dR27p26xDOnmNCcMn7Xh9OQzwYmMsnRAV8nZ8GS4qUz8y5+6t1TCsvvHObepfyUd15iIl+B1cp7EwcBSNJSo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371236; c=relaxed/simple; bh=4yn7atkLY4VoR4yZSg8W1k7y4dGJkuMgymIGq2IYHO8=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=jTuwSeBOk+FYXUJzIWObktVTH9fMlzhqMEpN1S18UUqYPNqbau2eC1SCOXmga9AlYFMibT34LL4UeoWon3x5dJZzMVt6UJBG/tiV2Z97nNGWalI15vqBtKLG+SCFXyDFS66CtscmvTzTsP39FoXDRFkgTSACD47wQ3fK2NkcFXU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Hyc2SyL5; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Hyc2SyL5" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 2BE31C4AF14; Fri, 23 Aug 2024 00:00:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724371236; bh=4yn7atkLY4VoR4yZSg8W1k7y4dGJkuMgymIGq2IYHO8=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=Hyc2SyL59CTvPLiIKpmvPQ2nr23ZUclaXDIuyWQ5e1dmQ5aDisXxz6wO5OIYQoAx7 5+X4JLvSwzvPSpF7tl5XSnDzE9Ol3zahjgf9X0UXBwOoNjp8vh0eD1VOh5pOxeNfnD J/Ulxw3EtcFGy6hCJQVc+syt5VaahBtX17t20GV6q7wLi1AcD9pno3puBStWLDJyUS SaT1hLjTYKR663W6WpagHtLeIPV1vs5g4tykL8afBNsruOUZdoWpdJh4cfn8Ob5G4E VVjyUK48vQFiOLzY7nJ4j3qC9Ww2m9E3YVi68fetRHWPsAhOIiPsDc29lrX/kHb/iL wrAr+r+HScbUA== Date: Thu, 22 Aug 2024 17:00:35 -0700 Subject: [PATCH 7/9] xfs: Fix missing interval for missing_owner in xfs fsmap From: "Darrick J. Wong" To: djwong@kernel.org Cc: Zizhi Wo , hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <172437083870.56860.9286016304300766439.stgit@frogsfrogsfrogs> In-Reply-To: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> References: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Zizhi Wo In the fsmap query of xfs, there is an interval missing problem: [root@fedora ~]# xfs_io -c 'fsmap -vvvv' /mnt EXT: DEV BLOCK-RANGE OWNER FILE-OFFSET AG AG-OFFSET TOTAL 0: 253:16 [0..7]: static fs metadata 0 (0..7) 8 1: 253:16 [8..23]: per-AG metadata 0 (8..23) 16 2: 253:16 [24..39]: inode btree 0 (24..39) 16 3: 253:16 [40..47]: per-AG metadata 0 (40..47) 8 4: 253:16 [48..55]: refcount btree 0 (48..55) 8 5: 253:16 [56..103]: per-AG metadata 0 (56..103) 48 6: 253:16 [104..127]: free space 0 (104..127) 24 ...... BUG: [root@fedora ~]# xfs_io -c 'fsmap -vvvv -d 104 107' /mnt [root@fedora ~]# Normally, we should be able to get [104, 107), but we got nothing. The problem is caused by shifting. The query for the problem-triggered scenario is for the missing_owner interval (e.g. freespace in rmapbt/ unknown space in bnobt), which is obtained by subtraction (gap). For this scenario, the interval is obtained by info->last. However, rec_daddr is calculated based on the start_block recorded in key[1], which is converted by calling XFS_BB_TO_FSBT. Then if rec_daddr does not exceed info->next_daddr, which means keys[1].fmr_physical >> (mp)->m_blkbb_log <= info->next_daddr, no records will be displayed. In the above example, 104 >> (mp)->m_blkbb_log = 12 and 107 >> (mp)->m_blkbb_log = 12, so the two are reduced to 0 and the gap is ignored: before calculate ----------------> after shifting 104(st) 107(ed) 12(st/ed) |---------| | sector size block size Resolve this issue by introducing the "end_daddr" field in xfs_getfsmap_info. This records |key[1].fmr_physical + key[1].length| at the granularity of sector. If the current query is the last, the rec_daddr is end_daddr to prevent missing interval problems caused by shifting. We only need to focus on the last query, because xfs disks are internally aligned with disk blocksize that are powers of two and minimum 512, so there is no problem with shifting in previous queries. After applying this patch, the above problem have been solved: [root@fedora ~]# xfs_io -c 'fsmap -vvvv -d 104 107' /mnt EXT: DEV BLOCK-RANGE OWNER FILE-OFFSET AG AG-OFFSET TOTAL 0: 253:16 [104..106]: free space 0 (104..106) 3 Fixes: e89c041338ed ("xfs: implement the GETFSMAP ioctl") Signed-off-by: Zizhi Wo Reviewed-by: Darrick J. Wong [djwong: limit the range of end_addr correctly] Signed-off-by: Darrick J. Wong --- fs/xfs/xfs_fsmap.c | 24 +++++++++++++++++++++++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/fs/xfs/xfs_fsmap.c b/fs/xfs/xfs_fsmap.c index 613a0ec204120..71f32354944e4 100644 --- a/fs/xfs/xfs_fsmap.c +++ b/fs/xfs/xfs_fsmap.c @@ -162,6 +162,7 @@ struct xfs_getfsmap_info { xfs_daddr_t next_daddr; /* next daddr we expect */ /* daddr of low fsmap key when we're using the rtbitmap */ xfs_daddr_t low_daddr; + xfs_daddr_t end_daddr; /* daddr of high fsmap key */ u64 missing_owner; /* owner of holes */ u32 dev; /* device id */ /* @@ -182,6 +183,7 @@ struct xfs_getfsmap_dev { int (*fn)(struct xfs_trans *tp, const struct xfs_fsmap *keys, struct xfs_getfsmap_info *info); + sector_t nr_sectors; }; /* Compare two getfsmap device handlers. */ @@ -294,6 +296,18 @@ xfs_getfsmap_helper( return 0; } + /* + * For an info->last query, we're looking for a gap between the last + * mapping emitted and the high key specified by userspace. If the + * user's query spans less than 1 fsblock, then info->high and + * info->low will have the same rm_startblock, which causes rec_daddr + * and next_daddr to be the same. Therefore, use the end_daddr that + * we calculated from userspace's high key to synthesize the record. + * Note that if the btree query found a mapping, there won't be a gap. + */ + if (info->last && info->end_daddr != XFS_BUF_DADDR_NULL) + rec_daddr = info->end_daddr; + /* Are we just counting mappings? */ if (info->head->fmh_count == 0) { if (info->head->fmh_entries == UINT_MAX) @@ -904,17 +918,21 @@ xfs_getfsmap( /* Set up our device handlers. */ memset(handlers, 0, sizeof(handlers)); + handlers[0].nr_sectors = XFS_FSB_TO_BB(mp, mp->m_sb.sb_dblocks); handlers[0].dev = new_encode_dev(mp->m_ddev_targp->bt_dev); if (use_rmap) handlers[0].fn = xfs_getfsmap_datadev_rmapbt; else handlers[0].fn = xfs_getfsmap_datadev_bnobt; if (mp->m_logdev_targp != mp->m_ddev_targp) { + handlers[1].nr_sectors = XFS_FSB_TO_BB(mp, + mp->m_sb.sb_logblocks); handlers[1].dev = new_encode_dev(mp->m_logdev_targp->bt_dev); handlers[1].fn = xfs_getfsmap_logdev; } #ifdef CONFIG_XFS_RT if (mp->m_rtdev_targp) { + handlers[2].nr_sectors = XFS_FSB_TO_BB(mp, mp->m_sb.sb_rblocks); handlers[2].dev = new_encode_dev(mp->m_rtdev_targp->bt_dev); handlers[2].fn = xfs_getfsmap_rtdev_rtbitmap; } @@ -946,6 +964,7 @@ xfs_getfsmap( info.next_daddr = head->fmh_keys[0].fmr_physical + head->fmh_keys[0].fmr_length; + info.end_daddr = XFS_BUF_DADDR_NULL; info.fsmap_recs = fsmap_recs; info.head = head; @@ -966,8 +985,11 @@ xfs_getfsmap( * low key, zero out the low key so that we get * everything from the beginning. */ - if (handlers[i].dev == head->fmh_keys[1].fmr_device) + if (handlers[i].dev == head->fmh_keys[1].fmr_device) { dkeys[1] = head->fmh_keys[1]; + info.end_daddr = min(handlers[i].nr_sectors - 1, + dkeys[1].fmr_physical); + } if (handlers[i].dev > head->fmh_keys[0].fmr_device) memset(&dkeys[0], 0, sizeof(struct xfs_fsmap)); From patchwork Fri Aug 23 00:00:51 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13774355 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EF05013A271 for ; Fri, 23 Aug 2024 00:00:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371252; cv=none; b=J5FbY5Ieyqy7LocKdyKxOHJNhm4Pk79hPigF0ZBudzVfz0eQolD1Bi2uX2qIychgjdAiBDSJoYNDQFiZ6E4cWLFEAAfzUsvrjz5b2Wsy0PgVw96Dltfux7czu8J8pf0RR2ML2i1efEEB23KYrqQR8zIesM2ljx2uPh9p40v4XRE= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371252; c=relaxed/simple; bh=bM0P8wXCQQxXmJaK9G7PVxUIjvmqQj7yirCtaafIK3k=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=sxEMtYRr4lcdBggyvMNhVRKo3n9wUnhlO+Oh1JDJiWD3CwnSMHxO9COoGZ7Eh8bsqiP9Cp20PRqnWgygccl1fEjU4y5iCL7hLWBOaVDjH9Y9o8PhtjK8BqhTC72U4SGNk4S/uTyIzKPxiJYOBj7B2nzJ/EjJQT+ZEq6mCBS8fN0= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=sWpbN3bV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="sWpbN3bV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CD1CBC4AF0E; Fri, 23 Aug 2024 00:00:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724371251; bh=bM0P8wXCQQxXmJaK9G7PVxUIjvmqQj7yirCtaafIK3k=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=sWpbN3bVruSCzzgRFkYy68xvwykG9WCJniuixmg5iifhX4WjrcEdbeYbRhyU/ejvc qhC0VdODg7WsXLBiFdUJKoV9F3yeBoY1Rt+J6OWSSWMI0eFFM69fN0gRU2ro5ytiX/ 9vvSsb3/XStqTgzhId/JLVD6gHfBSH+s2I3a9UAZ8rhxw+u9DJe8Gth7Jlz4z/u9lJ 9T4sLmzul8FNnCalRVdrthZbHVOWlIE38f2m/DoA0sWe20MMBGdfYFYFUpdAln5CuC jWElTjoYPqd1T/fUvnrujNDiNHRVyjEDPsQfpq9iw06kqcKW4/oL/+xbnx8dCBNfau HYs3ELIM1ZOMw== Date: Thu, 22 Aug 2024 17:00:51 -0700 Subject: [PATCH 8/9] xfs: take m_growlock when running growfsrt From: "Darrick J. Wong" To: djwong@kernel.org Cc: hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <172437083888.56860.4421290709549600558.stgit@frogsfrogsfrogs> In-Reply-To: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> References: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Take the grow lock when we're expanding the realtime volume, like we do for the other growfs calls. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- fs/xfs/xfs_rtalloc.c | 38 +++++++++++++++++++++++++------------- 1 file changed, 25 insertions(+), 13 deletions(-) diff --git a/fs/xfs/xfs_rtalloc.c b/fs/xfs/xfs_rtalloc.c index 0c3e96c621a67..776d6c401f62f 100644 --- a/fs/xfs/xfs_rtalloc.c +++ b/fs/xfs/xfs_rtalloc.c @@ -821,34 +821,39 @@ xfs_growfs_rt( /* Needs to have been mounted with an rt device. */ if (!XFS_IS_REALTIME_MOUNT(mp)) return -EINVAL; + + if (!mutex_trylock(&mp->m_growlock)) + return -EWOULDBLOCK; /* * Mount should fail if the rt bitmap/summary files don't load, but * we'll check anyway. */ + error = -EINVAL; if (!mp->m_rbmip || !mp->m_rsumip) - return -EINVAL; + goto out_unlock; /* Shrink not supported. */ if (in->newblocks <= sbp->sb_rblocks) - return -EINVAL; + goto out_unlock; /* Can only change rt extent size when adding rt volume. */ if (sbp->sb_rblocks > 0 && in->extsize != sbp->sb_rextsize) - return -EINVAL; + goto out_unlock; /* Range check the extent size. */ if (XFS_FSB_TO_B(mp, in->extsize) > XFS_MAX_RTEXTSIZE || XFS_FSB_TO_B(mp, in->extsize) < XFS_MIN_RTEXTSIZE) - return -EINVAL; + goto out_unlock; /* Unsupported realtime features. */ + error = -EOPNOTSUPP; if (xfs_has_rmapbt(mp) || xfs_has_reflink(mp) || xfs_has_quota(mp)) - return -EOPNOTSUPP; + goto out_unlock; nrblocks = in->newblocks; error = xfs_sb_validate_fsb_count(sbp, nrblocks); if (error) - return error; + goto out_unlock; /* * Read in the last block of the device, make sure it exists. */ @@ -856,7 +861,7 @@ xfs_growfs_rt( XFS_FSB_TO_BB(mp, nrblocks - 1), XFS_FSB_TO_BB(mp, 1), 0, &bp, NULL); if (error) - return error; + goto out_unlock; xfs_buf_relse(bp); /* @@ -864,8 +869,10 @@ xfs_growfs_rt( */ nrextents = nrblocks; do_div(nrextents, in->extsize); - if (!xfs_validate_rtextents(nrextents)) - return -EINVAL; + if (!xfs_validate_rtextents(nrextents)) { + error = -EINVAL; + goto out_unlock; + } nrbmblocks = xfs_rtbitmap_blockcount(mp, nrextents); nrextslog = xfs_compute_rextslog(nrextents); nrsumlevels = nrextslog + 1; @@ -876,8 +883,11 @@ xfs_growfs_rt( * the log. This prevents us from getting a log overflow, * since we'll log basically the whole summary file at once. */ - if (nrsumblocks > (mp->m_sb.sb_logblocks >> 1)) - return -EINVAL; + if (nrsumblocks > (mp->m_sb.sb_logblocks >> 1)) { + error = -EINVAL; + goto out_unlock; + } + /* * Get the old block counts for bitmap and summary inodes. * These can't change since other growfs callers are locked out. @@ -889,10 +899,10 @@ xfs_growfs_rt( */ error = xfs_growfs_rt_alloc(mp, rbmblocks, nrbmblocks, mp->m_rbmip); if (error) - return error; + goto out_unlock; error = xfs_growfs_rt_alloc(mp, rsumblocks, nrsumblocks, mp->m_rsumip); if (error) - return error; + goto out_unlock; rsum_cache = mp->m_rsum_cache; if (nrbmblocks != sbp->sb_rbmblocks) @@ -1059,6 +1069,8 @@ xfs_growfs_rt( } } +out_unlock: + mutex_unlock(&mp->m_growlock); return error; } From patchwork Fri Aug 23 00:01:07 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 13774356 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DEA23620 for ; Fri, 23 Aug 2024 00:01:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371267; cv=none; b=urmVltysL+BS8uskD921oLESBXS4X4Uxu8uegsTuubzJrh5lD/Idigd0um8QfFhzdg4X1ouT20Nmb/CKQCejonz2dITC3ZvO0MqahiXwamWQfEz8d1/M1xmpQMAnf4CueCaD2r8+DNXhfyaYcgYSQfEvEbu3keV0356kkH8+xAg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1724371267; c=relaxed/simple; bh=s0E+oOFibR+7/dofV4XSkWiEyLRmZZPRwLlbARikCYQ=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=QUjw0tQmlrdLEhGARPavMv2G3mJgYXLUsjUKpSsqFmuck2GY0IY6Gm2KS7KKuNQyUXWJgika71vWQMt4eyuhdLFvULE5nziTTUPZUwO4jf9qw2RbMmK67WOFbW12OIDwmmQ9Zb0jSuZGwVbOXPRy68tefM8Kg1Ep09IwM92/QOA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=aILUMCrV; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="aILUMCrV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B4C4C32782; Fri, 23 Aug 2024 00:01:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1724371267; bh=s0E+oOFibR+7/dofV4XSkWiEyLRmZZPRwLlbARikCYQ=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=aILUMCrV6j6roVSkxtDJdtfIYD3EpSPTLRmtMV14RGwyZWv53cBmVy1v6uXQSa0bj H/MRb6qV0yHiqf21wA7Qwy7lK5WnGm8pduWnbPLk+XZVfX6C/RixcpupcfOgN/5opX PjatXU5PIsnXVImRK7MtkWM4+CDKbAPgO7+Dv3h8fTAc8ACYOsASF7Owh15Zp9KCZr nbUnTNQJXwWrRIZjQtOwp3PjhKUJw6BrG4a//xLWoAdcPO/AK7XvfhM0rsolRwICYS mupU5zOKEZCF/PuWgNt1Li0nqvinb+ZXrbby/vzd8hSZeBGlOF0rhDbnmzl8MZRaSw OkN0H1XVOilxg== Date: Thu, 22 Aug 2024 17:01:07 -0700 Subject: [PATCH 9/9] xfs: reset rootdir extent size hint after growfsrt From: "Darrick J. Wong" To: djwong@kernel.org Cc: hch@lst.de, linux-xfs@vger.kernel.org Message-ID: <172437083905.56860.4443371257049623802.stgit@frogsfrogsfrogs> In-Reply-To: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> References: <172437083728.56860.10056307551249098606.stgit@frogsfrogsfrogs> User-Agent: StGit/0.19 Precedence: bulk X-Mailing-List: linux-xfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong If growfsrt is run on a filesystem that doesn't have a rt volume, it's possible to change the rt extent size. If the root directory was previously set up with an inherited extent size hint and rtinherit, it's possible that the hint is no longer a multiple of the rt extent size. Although the verifiers don't complain about this, xfs_repair will, so if we detect this situation, log the root directory to clean it up. This is still racy, but it's better than nothing. Signed-off-by: Darrick J. Wong Reviewed-by: Christoph Hellwig --- fs/xfs/xfs_rtalloc.c | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/fs/xfs/xfs_rtalloc.c b/fs/xfs/xfs_rtalloc.c index 776d6c401f62f..ebeab8e4dab10 100644 --- a/fs/xfs/xfs_rtalloc.c +++ b/fs/xfs/xfs_rtalloc.c @@ -784,6 +784,39 @@ xfs_alloc_rsum_cache( xfs_warn(mp, "could not allocate realtime summary cache"); } +/* + * If we changed the rt extent size (meaning there was no rt volume previously) + * and the root directory had EXTSZINHERIT and RTINHERIT set, it's possible + * that the extent size hint on the root directory is no longer congruent with + * the new rt extent size. Log the rootdir inode to fix this. + */ +static int +xfs_growfs_rt_fixup_extsize( + struct xfs_mount *mp) +{ + struct xfs_inode *ip = mp->m_rootip; + struct xfs_trans *tp; + int error = 0; + + xfs_ilock(ip, XFS_IOLOCK_EXCL); + if (!(ip->i_diflags & XFS_DIFLAG_RTINHERIT) || + !(ip->i_diflags & XFS_DIFLAG_EXTSZINHERIT)) + goto out_iolock; + + error = xfs_trans_alloc_inode(ip, &M_RES(mp)->tr_ichange, 0, 0, false, + &tp); + if (error) + goto out_iolock; + + xfs_trans_log_inode(tp, ip, XFS_ILOG_CORE); + error = xfs_trans_commit(tp); + xfs_iunlock(ip, XFS_ILOCK_EXCL); + +out_iolock: + xfs_iunlock(ip, XFS_IOLOCK_EXCL); + return error; +} + /* * Visible (exported) functions. */ @@ -812,6 +845,7 @@ xfs_growfs_rt( xfs_extlen_t rsumblocks; /* current number of rt summary blks */ xfs_sb_t *sbp; /* old superblock */ uint8_t *rsum_cache; /* old summary cache */ + xfs_agblock_t old_rextsize = mp->m_sb.sb_rextsize; sbp = &mp->m_sb; @@ -1046,6 +1080,12 @@ xfs_growfs_rt( if (error) goto out_free; + if (old_rextsize != in->extsize) { + error = xfs_growfs_rt_fixup_extsize(mp); + if (error) + goto out_free; + } + /* Update secondary superblocks now the physical grow has completed */ error = xfs_update_secondary_sbs(mp);