From patchwork Thu Jul 28 18:17:15 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12931647 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id CAA60C04A68 for ; Thu, 28 Jul 2022 18:17:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231925AbiG1SRU (ORCPT ); Thu, 28 Jul 2022 14:17:20 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49178 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231688AbiG1SRS (ORCPT ); Thu, 28 Jul 2022 14:17:18 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3EA93558D7; Thu, 28 Jul 2022 11:17:18 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id DD172B824D5; Thu, 28 Jul 2022 18:17:16 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A310C433D7; Thu, 28 Jul 2022 18:17:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659032235; bh=ZMRRftXBZYRdKNYNL9eP7mpuXRuvArnl5y1ivd03ZP4=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=ZN7AE32tF0vQed8lZJsa7w7JPULYdRo+V6wNZx3snQmWkAepDNY2hflJdvlb0Rxih qClEt4/Njuf+L6ZDL/PklAwPpB3XiZDvMIce1Ke3IUQ3Ge1x1T5gt6ga1iXOm+YML0 h2niG5jSDRPDdMZPcya5LqyTkYH5QYJzQN7zLjNBPU/QlPNJw92V/rRA8sd65T4udp gdS5Fddze2WAT65s8z2qeJeQRJWfiZyDmw+FxkIfVV+ycmLVCv6LcsLpdIjX37MWfl p4fjF61G9o5R9oVz5Dzt09D5C4/kCAExJ4+J6prZVI9Tr4jSHuleOQwZq2ieEQuUXL dD9WGPHN9YYVQ== Subject: [PATCH 1/3] xfs/432: fix this test when external devices are in use From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Thu, 28 Jul 2022 11:17:15 -0700 Message-ID: <165903223512.2338516.9583051314883581667.stgit@magnolia> In-Reply-To: <165903222941.2338516.818684834175743726.stgit@magnolia> References: <165903222941.2338516.818684834175743726.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Darrick J. Wong This program exercises metadump and mdrestore being run against the scratch device. Therefore, the test must pass external log / rt device arguments to xfs_repair -n to check the "restored" filesystem. Fix the incorrect usage, and report repair failures, since this test has been silently failing for a while now. Signed-off-by: Darrick J. Wong --- tests/xfs/432 | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tests/xfs/432 b/tests/xfs/432 index 86012f0b..e1e610d0 100755 --- a/tests/xfs/432 +++ b/tests/xfs/432 @@ -89,7 +89,8 @@ _scratch_xfs_metadump $metadump_file -w xfs_mdrestore $metadump_file $metadump_img echo "Check restored metadump image" -$XFS_REPAIR_PROG -n $metadump_img >> $seqres.full 2>&1 +SCRATCH_DEV=$metadump_img _scratch_xfs_repair -n &>> $seqres.full || \ + echo "xfs_repair on restored fs returned $?" # success, all done status=0 From patchwork Thu Jul 28 18:17:20 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12931648 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id AFA8AC04A68 for ; Thu, 28 Jul 2022 18:17:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231959AbiG1SRZ (ORCPT ); Thu, 28 Jul 2022 14:17:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49220 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231688AbiG1SRY (ORCPT ); Thu, 28 Jul 2022 14:17:24 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E128B5F9AB; Thu, 28 Jul 2022 11:17:23 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 8D6FCB824D7; Thu, 28 Jul 2022 18:17:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 45376C433D6; Thu, 28 Jul 2022 18:17:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659032241; bh=4SM+xsPZ1++hpEVq3WRJzUiT4xpxCOrjhvSn7fUSoas=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=pAz3ZLqc+uzXkcOkgdNxhIkbnolZzg3kq5XVtYBvULnOjERXCylt0Cl2nCkkBa/w/ AnbOa0f1XrY8cCSIsZxhJglvUN3hhYlYfiFnC10g/nRxmegPAgga6cVvbi4IKtonC6 HFDy0y/Kiinb8xD6+TqN1HUOtbnYKHnzyCnDLTfbNJAoEgUr4yTztVgpRisbweQxdB DpVbv/KuXVYar9uqwY+nGClhttbbKV1fdZOAybeZBXwceufxjA9oOza7wYbFGu+MPD Fjv5aU2oG9yYEvOaqNWK3nx5PzfCxX6ILRaSApW55JRE5m74LPWUuSFYlwISW77F7z +8XiPS8rOScBw== Subject: [PATCH 2/3] xfs/291: convert open-coded _scratch_xfs_repair usage From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com, zlang@redhat.com Cc: linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Thu, 28 Jul 2022 11:17:20 -0700 Message-ID: <165903224078.2338516.14554764802610406233.stgit@magnolia> In-Reply-To: <165903222941.2338516.818684834175743726.stgit@magnolia> References: <165903222941.2338516.818684834175743726.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Darrick J. Wong Convert this test to use _scratch_xfs_repair, since the only variance from the standard usage is that it's called against a sparse file into which the scratch filesystem has been metadumped and mdrestored. Signed-off-by: Darrick J. Wong --- tests/xfs/291 | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) diff --git a/tests/xfs/291 b/tests/xfs/291 index 6d5e247e..a2425e47 100755 --- a/tests/xfs/291 +++ b/tests/xfs/291 @@ -93,11 +93,7 @@ _scratch_xfs_check >> $seqres.full 2>&1 || _fail "xfs_check failed" # Can xfs_metadump cope with this monster? _scratch_xfs_metadump $tmp.metadump || _fail "xfs_metadump failed" xfs_mdrestore $tmp.metadump $tmp.img || _fail "xfs_mdrestore failed" -[ "$USE_EXTERNAL" = yes ] && [ -n "$SCRATCH_RTDEV" ] && \ - rt_repair_opts="-r $SCRATCH_RTDEV" -[ "$USE_EXTERNAL" = yes ] && [ -n "$SCRATCH_LOGDEV" ] && \ - log_repair_opts="-l $SCRATCH_LOGDEV" -$XFS_REPAIR_PROG $rt_repair_opts $log_repair_opts -f $tmp.img >> $seqres.full 2>&1 || \ +SCRATCH_DEV=$tmp.img _scratch_xfs_repair -f &>> $seqres.full || \ _fail "xfs_repair of metadump failed" # Yes it can; success, all done From patchwork Thu Jul 28 18:17:26 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 12931649 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id D570CC04A68 for ; Thu, 28 Jul 2022 18:17:31 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232341AbiG1SRb (ORCPT ); Thu, 28 Jul 2022 14:17:31 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49264 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231688AbiG1SRa (ORCPT ); Thu, 28 Jul 2022 14:17:30 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A8E446053E; Thu, 28 Jul 2022 11:17:29 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 51AD3B824DA; Thu, 28 Jul 2022 18:17:28 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id DC039C433C1; Thu, 28 Jul 2022 18:17:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1659032246; bh=qA7jtNsv7LzYSOnmo1TQj1iYXWIxa+f5Fv6H06m0ysk=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=YLBRk1MLNIzAPeCSZdIxcm2g6p6+LS1ngbexIaauwtcr05ikEvTUAzN7Qq+RFeNKb QfRAp/AhzurRoBMZccmDrej7Xse+JVc7P4z/BJqiA2eJz67DqiWbpFzHPtT7h3w3DB JvHGa2dKHr/p3WVpSE7LGmj4QpoksFlzT7pETokxsmOqvn3jjKZ9uWSlQzplEkqXFi NNRQ4ndo9EFmgoy/mwxzl/rzwKpEUy3CXPi9dEZu2mLIRcXh3JeMgk8j0lFceQpbi6 f+jn475T53GYP7Fcz5PfI6aMaLY8ep8QFojZmIP72C+cbsKi1X7vV1zuHpzP5Xqymg oxm6V8ILE3QTQ== Subject: [PATCH 3/3] seek_sanity_test: use XFS ioctls to determine file allocation unit size From: "Darrick J. Wong" To: djwong@kernel.org, guaneryu@gmail.com, zlang@redhat.com Cc: liuyd.fnst@fujitsu.com, liuyd.fnst@fujitsu.com, linux-xfs@vger.kernel.org, fstests@vger.kernel.org, guan@eryu.me Date: Thu, 28 Jul 2022 11:17:26 -0700 Message-ID: <165903224646.2338516.11839049913536195078.stgit@magnolia> In-Reply-To: <165903222941.2338516.818684834175743726.stgit@magnolia> References: <165903222941.2338516.818684834175743726.stgit@magnolia> User-Agent: StGit/0.19 MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: fstests@vger.kernel.org From: Darrick J. Wong liuyd.fnst@fujitsu.com reported that my recent change to the seek sanity test broke NFS. I foolishly thought that st_blksize was sufficient to find the file allocation unit size so that applications could figure out the SEEK_HOLE granularity. Replace that with an explicit callout to XFS ioctls so that xfs realtime will work again. Fixes: e861a302 ("seek_sanity_test: fix allocation unit detection on XFS realtime") Reported-by: liuyd.fnst@fujitsu.com Tested-by: liuyd.fnst@fujitsu.com Signed-off-by: Darrick J. Wong Reviewed-by: Zorro Lang --- src/seek_sanity_test.c | 36 +++++++++++++++++++++++++++--------- 1 file changed, 27 insertions(+), 9 deletions(-) diff --git a/src/seek_sanity_test.c b/src/seek_sanity_test.c index 1030d0c5..78f835e8 100644 --- a/src/seek_sanity_test.c +++ b/src/seek_sanity_test.c @@ -40,6 +40,28 @@ static void get_file_system(int fd) } } +/* Compute the file allocation unit size for an XFS file. */ +static int detect_xfs_alloc_unit(int fd) +{ + struct fsxattr fsx; + struct xfs_fsop_geom fsgeom; + int ret; + + ret = ioctl(fd, XFS_IOC_FSGEOMETRY, &fsgeom); + if (ret) + return -1; + + ret = ioctl(fd, XFS_IOC_FSGETXATTR, &fsx); + if (ret) + return -1; + + alloc_size = fsgeom.blocksize; + if (fsx.fsx_xflags & XFS_XFLAG_REALTIME) + alloc_size *= fsgeom.rtextsize; + + return 0; +} + static int get_io_sizes(int fd) { off_t pos = 0, offset = 1; @@ -47,6 +69,10 @@ static int get_io_sizes(int fd) int shift, ret; int pagesz = sysconf(_SC_PAGE_SIZE); + ret = detect_xfs_alloc_unit(fd); + if (!ret) + goto done; + ret = fstat(fd, &buf); if (ret) { fprintf(stderr, " ERROR %d: Failed to find io blocksize\n", @@ -54,16 +80,8 @@ static int get_io_sizes(int fd) return ret; } - /* - * st_blksize is typically also the allocation size. However, XFS - * rounds this up to the page size, so if the stat blocksize is exactly - * one page, use this iterative algorithm to see if SEEK_DATA will hint - * at a more precise answer based on the filesystem's (pre)allocation - * decisions. - */ + /* st_blksize is typically also the allocation size */ alloc_size = buf.st_blksize; - if (alloc_size != pagesz) - goto done; /* try to discover the actual alloc size */ while (pos == 0 && offset < alloc_size) {