From patchwork Fri Mar 21 21:27:38 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 14026066 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 A3D9A1EE005; Fri, 21 Mar 2025 21:27:39 +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=1742592459; cv=none; b=GTjOb4h5jEewYqAbrgJ+51VoMGCm4n5mrGVsbeEH0ZERhFDGbJVbmT5ura5hFE0X/MRONd8n3pMTRdSKRkl9+PYvSseGgq4c2YaPrtrgefCbmezqwOIl6NVLS9EFpVy0gY17gwPLw+i2s8S7p59SADyTixIqnNe6ASqb3DjHTJM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742592459; c=relaxed/simple; bh=oydxMkyc0hiknia09FS2tFcW+lBSuiAv++SGfwgd+xw=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=NTtyiJ63uvwvHWABkc7ITjW9z6qXcamD/DWV/LBHvwbbPaP+mv0xKfxksWCdtuBF/lX0H4So/wnlVajNyUg3K0Ry224qt4ytS6OOFiTIZA+Kc0rQoXvlJ3M6jeSEEPyhygu0eNP8UwszDSEDPvDSM+l+dbbT7ZRELGkM8ikl6uQ= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NBUeVaMy; 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="NBUeVaMy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DAA7C4CEE3; Fri, 21 Mar 2025 21:27:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742592459; bh=oydxMkyc0hiknia09FS2tFcW+lBSuiAv++SGfwgd+xw=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=NBUeVaMyosMbghyqOOtm5JfkbrdDDPnTJewG2WvZP6vDWke8Vb/of0gjCV1NC4jPg cf9UBVLX7TEa5NHGHUBG13TQBIOtp9HaJ/ArG+ZPH06xht59gpe29oSGGBs4KaGtOY WjqYrGOwNn0NlRlddapEDe4P7RREwMfvtgYNnGMYc9A2hrMXTP2z0/5bHUKtJC9Gsx 8235WwtNvoZgKb8YafgjS96meOI4JabGgWr2OIHZA9/dRRoZHYFZD+NQA3p/vJIK+o F5skqf5jqcbdqTbz/20bqojFn/ubSIgig2YPMvj2uuquwSc5vs+Q9+HU5AmP7/D+Dc k2Y3LrA7oVyaA== Date: Fri, 21 Mar 2025 14:27:38 -0700 Subject: [PATCH 1/4] xfs/614: determine the sector size of the fs image by doing a test format From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: hch@lst.de, hch@lst.de, linux-xfs@vger.kernel.org, fstests@vger.kernel.org Message-ID: <174259233981.743619.4539343498817899229.stgit@frogsfrogsfrogs> In-Reply-To: <174259233946.743619.993544237516250761.stgit@frogsfrogsfrogs> References: <174259233946.743619.993544237516250761.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong In some cases (such as xfs always_cow=1), the configuration of the test filesystem determines the sector size of the filesystem that we're going to simulate formatting. Concretely, even if TEST_DEV is a block device with 512b sectors, the directio geometry can specify 4k writes to avoid nasty RMW cycles. When this happens, mkfs.xfs will set the sector size to that 4k accordingly, but the golden output selection is wrong. Fix this. Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig --- tests/xfs/614 | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/tests/xfs/614 b/tests/xfs/614 index 2a799fbf3ed71c..e182f073fddd64 100755 --- a/tests/xfs/614 +++ b/tests/xfs/614 @@ -25,13 +25,16 @@ _require_test $MKFS_XFS_PROG 2>&1 | grep -q concurrency || \ _notrun "mkfs does not support concurrency options" -test_dev_lbasize=$(blockdev --getss $TEST_DEV) -seqfull=$0 -_link_out_file "lba${test_dev_lbasize}" - +# Figure out what sector size mkfs will use to format, which might be dependent +# upon the directio write geometry of the test filesystem. loop_file=$TEST_DIR/$seq.loop - rm -f "$loop_file" +truncate -s 16M "$loop_file" +$MKFS_XFS_PROG -f -N "$loop_file" | _filter_mkfs 2>$tmp.mkfs >/dev/null +. $tmp.mkfs +seqfull=$0 +_link_out_file "lba${sectsz}" + for sz in 16M 512M 1G 2G 16G 64G 256G 512G 1T 2T 4T 16T 64T 256T 512T 1P; do for cpus in 2 4 8 16 32 40 64 96 160 512; do truncate -s "$sz" "$loop_file" From patchwork Fri Mar 21 21:27:54 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 14026067 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 559E022AE75; Fri, 21 Mar 2025 21:27:55 +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=1742592478; cv=none; b=oo0VXfSA1HqfA1ZU29tJ5WK/Rshz2BoJCJ29DMAVFflZnRCW2CNpE8KloB1CF5JUk1z1lXWNsNqf3BYwwEHjRqmPAa5WdLBDV1NEHpueluOToyFnVBKxPWxOztFswovMCI+3NqHb/FuzxlOL64Y344KfV3yovz6ABEBvT44aEio= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742592478; c=relaxed/simple; bh=7md1fT4J8la6NB8X5MqoHWWlkWJ5c5EnxluckLLYGjE=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ck/s3maKhL/O5q4Kj6EI8Nks2tHppd38WOIU9N3ya+01lwqeS6cQHiI7Q8XUnid6cY4xq3W415PtbwZfZh3aZfIwya7gDbMhxhC8UjoCZNkI6bXFqQtMoVUjFKkqEPLsa1C6E3AIF5k++UPfPHPb/34ANbRnysG+tIhsmLZlBBU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TEgEHLMp; 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="TEgEHLMp" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 87EAAC4CEE3; Fri, 21 Mar 2025 21:27:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742592475; bh=7md1fT4J8la6NB8X5MqoHWWlkWJ5c5EnxluckLLYGjE=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=TEgEHLMpa2rUGCvY644/EzchzOzWe/zPv2GSSwU2Y/T5Xz0PaAu2sNDoDlQ3hyCtZ 5kJH6T7gjveF+ocAjkRBPmmIHgk8EZg/xj29a1oh1xMQ/pybJr4U2xFd3Elg+yHxj7 uudmmf4RYGw5goI8spv3a50hXV/yGCIHj8RAs5uNB/kEc/9IewuIHNIz87Znm6PR/J k0S9JzoSuavAuybDhmmQQRnz5nubuvemmzmGuGboGYVFp7U/Isb0TKQ7pjKCxb9bR7 MVmXCCvI+28VJKLnNroHC4SIkTHP4p4JjJxExg1QesQChkOGDsmN3uStq8LuXZHI6H 59R+GNIVlqb3w== Date: Fri, 21 Mar 2025 14:27:54 -0700 Subject: [PATCH 2/4] generic/537: disable quota mount options for pre-metadir rt filesystems From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: hch@lst.de, linux-xfs@vger.kernel.org, fstests@vger.kernel.org Message-ID: <174259233999.743619.6582695769493412159.stgit@frogsfrogsfrogs> In-Reply-To: <174259233946.743619.993544237516250761.stgit@frogsfrogsfrogs> References: <174259233946.743619.993544237516250761.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong Fix this regression in generic/537: mount: /opt: permission denied. dmesg(1) may have more information after failed mount system call. mount -o uquota,gquota,pquota, -o ro,norecovery -ortdev=/dev/sdb4 /dev/sda4 /opt failed mount -o uquota,gquota,pquota, -o ro,norecovery -ortdev=/dev/sdb4 /dev/sda4 /opt failed (see /var/tmp/fstests/generic/537.full for details) for reasons explained in the giant comment. TLDR: quota and rt aren't compatible on older xfs filesystems so we have to work around that. Signed-off-by: "Darrick J. Wong" Reviewed-by: Zorro Lang --- tests/generic/537 | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/tests/generic/537 b/tests/generic/537 index f57bc1561dd57e..3be743c4133f4f 100755 --- a/tests/generic/537 +++ b/tests/generic/537 @@ -18,6 +18,7 @@ _begin_fstest auto quick trim # Import common functions. . ./common/filter +. ./common/quota _require_scratch _require_fstrim @@ -36,6 +37,22 @@ _scratch_mount -o ro >> $seqres.full 2>&1 $FSTRIM_PROG -v $SCRATCH_MNT >> $seqres.full 2>&1 _scratch_unmount +# As of kernel commit 9f0902091c332b ("xfs: Do not allow norecovery mount with +# quotacheck"), it is no longer possible to mount with "norecovery" and any +# quota mount option if the quota mount options would require a metadata update +# such as quotacheck. For a pre-metadir XFS filesystem with a realtime volume +# and quota-enabling options, the first two mount attempts will have succeeded +# but with quotas disabled. The mount option parsing for this next mount +# attempt will see the same quota-enabling options and a lack of qflags in the +# ondisk metadata and reject the mount because it thinks that will require +# quotacheck. Edit out the quota mount options for this specific +# configuration. +if [ "$FSTYP" = "xfs" ]; then + if [ "$USE_EXTERNAL" = "yes" ] && [ -n "$SCRATCH_RTDEV" ]; then + _qmount_option "" + fi +fi + echo "fstrim on ro mount with no log replay" norecovery="norecovery" test $FSTYP = "btrfs" && norecovery=nologreplay From patchwork Fri Mar 21 21:28:10 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 14026068 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 32B65231C9C; Fri, 21 Mar 2025 21:28:11 +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=1742592492; cv=none; b=EzBwu92E6wQqCiXHgT7949EhC/ASFgfZg9vS5CiHl4XROvP/V1tdoK0k87ugulhqEUP88lVSkiraPUf3KwW66KM6ZBslEFdAL8jkBdgz1FLoZwEdRMhRkz7Z0Y7HeVtMn6+kHGnIkNV+GVGSqVdvufMgc2Xz0xP2KoPd9z8J7mQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742592492; c=relaxed/simple; bh=mVOiviCv8uJtTr4gy0MKvCpfPl5bxRFzfKfog1sG0Og=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=pRJF67fj+jPMLcGRWNF1STaxcPtH/qGVI6c0fE7MoNHmbODVRtjPxYzbhe9gWSYfhTfXG68Ni63hcv8eVWX5/EBWcLBuPo36VZdfcQnBbBH0nmRN6dHghj/6n69MLxsjuWjJdp6xe+tr/ddHNHug/rM0Z0fPz+X/A6b2OdcOr0s= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=NcGMxgLc; 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="NcGMxgLc" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 617C5C4CEE3; Fri, 21 Mar 2025 21:28:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742592491; bh=mVOiviCv8uJtTr4gy0MKvCpfPl5bxRFzfKfog1sG0Og=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=NcGMxgLcQnCgJTC+hxtTTCHMgQ1R2iEvE1/bkMVlMYBsm+40JLtOzx+Xbs5VAcCXj jSi72kpVfWDWO8o8Fe41809LcVJHue++rv0Kkm5CHHD9O/Sxk0rR9DXTc5QwnTBIay 5TOs6S4acdyg9WBPMVgQiTvLEgyOVxC+8kxhopnl58sCNLn1DySimRsCVpN3Y0my6/ La5d4XsieF3UTjk/KFeTBXthHBnUf24cigA40cX6zS0TP+CkCs7MDt+SpW5/cSoThQ yALb+XYEwRNZNjEw7Sh5K+RebCMMFzfHtkwUftow5jjl7AUvDQFot4oEtHb3Sh+io5 xKvH09HOXv9VQ== Date: Fri, 21 Mar 2025 14:28:10 -0700 Subject: [PATCH 3/4] common/populate: drop fallocate mode 0 requirement From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: hch@lst.de, hch@lst.de, linux-xfs@vger.kernel.org, fstests@vger.kernel.org Message-ID: <174259234017.743619.10601450560372036830.stgit@frogsfrogsfrogs> In-Reply-To: <174259233946.743619.993544237516250761.stgit@frogsfrogsfrogs> References: <174259233946.743619.993544237516250761.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong None of the _scratch_$FSTYP_populate functions use fallocate mode 0 (aka preallocation) to run, so drop the _require check. This enables xfs/349 and friends to work on always-cow xfs filesystems. Signed-off-by: "Darrick J. Wong" Reviewed-by: Christoph Hellwig --- common/populate | 1 - 1 file changed, 1 deletion(-) diff --git a/common/populate b/common/populate index a1be26d5b24adf..7352f598a0c700 100644 --- a/common/populate +++ b/common/populate @@ -8,7 +8,6 @@ . ./common/quota _require_populate_commands() { - _require_xfs_io_command "falloc" _require_xfs_io_command "fpunch" _require_test_program "punch-alternating" _require_test_program "popdir.pl" From patchwork Fri Mar 21 21:28:26 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Darrick J. Wong" X-Patchwork-Id: 14026069 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 96D2E230D0F; Fri, 21 Mar 2025 21:28:27 +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=1742592507; cv=none; b=odugCOw0yKJEYuazkAbNVZFtdQCTtdEl/rqozUqPeQbNPAxtMgLsZtI8EStR85e8wtfS4ZS/OaTpJEUex6MV+LGZMrnBin4i8WD3HJ29X+Q84Ulo+cJqgjyOHwUXxNKjw1wxSfHZotfQ+OwDKD1VFOPT9fGI6Zwb0qXNejXkRY8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1742592507; c=relaxed/simple; bh=6XQfFPFWe8qmXzqEW5yZUQgzjBk4DuB1/FvHi8Ldxc4=; h=Date:Subject:From:To:Cc:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=uGkc6W7vtsf87uU8MByHleE6zUEqIyIlcXUnANt6ARkyGpBjt65I0T2D1I+AGjdfVR0fnfiCNgeAfvho6XNhwDWfl2UkpJigQvmVVA0woleTfd/5VM6r3/s0Nk7lch1QtjcGxk1nMKH8ZkOd1IuAMW1iS7ax61bQnbDUwzk/J1c= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=uUHi0orZ; 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="uUHi0orZ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 426F1C4CEE3; Fri, 21 Mar 2025 21:28:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1742592507; bh=6XQfFPFWe8qmXzqEW5yZUQgzjBk4DuB1/FvHi8Ldxc4=; h=Date:Subject:From:To:Cc:In-Reply-To:References:From; b=uUHi0orZ3RZdrglOJP7+m50vXDRlW9ZLd/U23lWACMZoK3cGWBmRjTMoo46B8Jodt tT99lnw4D3G6SHuOxJn0IDdCpXRDCl7LLUVjrbkOI7pjAaVf86VJugBPu5QtueQqtS ZQ4rX4+Dnl/Rxfwa3brsrjxezwGZTxRzWWQyF3VXhkhs1HtDRu2veNOk4lYeQzX3So +zHdbZq4N6Uq04k6k2PSUOqEryqpe1izaLEOYKo39HjcGTY4LSwFmwzwMPRYCQFJDa VS/XrwX8ATJaVHazXWgzAot4QpRj3umb7wh1yCrk9Pu7fBA0XQexNGsbiYXmfETFhD Pt3tS4BoSHLMw== Date: Fri, 21 Mar 2025 14:28:26 -0700 Subject: [PATCH 4/4] xfs/818: fix some design issues From: "Darrick J. Wong" To: djwong@kernel.org, zlang@redhat.com Cc: fstests@vger.kernel.org, hch@lst.de, linux-xfs@vger.kernel.org, fstests@vger.kernel.org Message-ID: <174259234036.743619.7066882477727740142.stgit@frogsfrogsfrogs> In-Reply-To: <174259233946.743619.993544237516250761.stgit@frogsfrogsfrogs> References: <174259233946.743619.993544237516250761.stgit@frogsfrogsfrogs> Precedence: bulk X-Mailing-List: fstests@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 From: Darrick J. Wong While QA'ing zoned filesystem support, I discovered some design errors in this test: 1) Since we're test formatting a sparse file on an xfs filesystem, there's no need to play games with optimal device size; we can create a totally sparse file that's the same size as SCRATCH_DEV. 2) mkfs.xfs cannot create realtime files, so if it fails with that, there's no need to continue the test. 3) If mkfs -p fails for none of the proscribed reasons, it should exit the test. The final cat $tmp.mkfs will take care of tweaking the golden output to register the test failure for further investigation. Cc: # v2025.03.09 Fixes: 6d39dc34e61e11 ("xfs: test filesystem creation with xfs_protofile") Signed-off-by: "Darrick J. Wong" Reviewed-by: Zorro Lang --- tests/xfs/818 | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/tests/xfs/818 b/tests/xfs/818 index aeb462353df7e9..bc809390b9e340 100755 --- a/tests/xfs/818 +++ b/tests/xfs/818 @@ -75,9 +75,8 @@ _run_fsstress -n 1000 -d $SCRATCH_MNT/newfiles make_stat $SCRATCH_MNT before make_md5 $SCRATCH_MNT before -kb_needed=$(du -k -s $SCRATCH_MNT | awk '{print $1}') -img_size=$((kb_needed * 2)) -test "$img_size" -lt $((300 * 1024)) && img_size=$((300 * 1024)) +scratch_sectors="$(blockdev --getsz $SCRATCH_DEV)" +img_size=$((scratch_sectors * 512 / 1024)) echo "Clone image with protofile" $XFS_PROTOFILE_PROG $SCRATCH_MNT > $testfiles/protofile @@ -99,7 +98,21 @@ if ! _try_mkfs_dev -p $testfiles/protofile $testfiles/image &> $tmp.mkfs; then if grep -q 'No space left on device' $tmp.mkfs; then _notrun "not enough space in filesystem" fi + + # mkfs cannot create realtime files. + # + # If zoned=1 is in MKFS_OPTIONS, mkfs will create an internal realtime + # volume with rtinherit=1 and fail, so we need to _notrun that case. + # + # If zoned=1 is /not/ in MKFS_OPTIONS, we didn't pass a realtime device + # to mkfs so it will not create realtime files. The format should work + # just fine. + if grep -q 'creating realtime files from proto file not supported' $tmp.mkfs; then + _notrun "mkfs cannot create realtime files" + fi + cat $tmp.mkfs + exit fi _mount $testfiles/image $testfiles/mount