[13/24] generic/204: don't flood stdout with ENOSPC messages on an ENOSPC test

Commit Message

Darrick J. Wong Sept. 15, 2020, 1:44 a.m. UTC

From: Darrick J. Wong <[e-mail]>

This test has been on and off my bad list for many years due to the fact
that it will spew potentially millions of "No space left on device"
errors if the file count calculations are wrong.  The calculations
should be correct for the XFS data device, but they don't apply to other
filesystems.

Therefore, filter out the ENOSPC messages when the files are not going
to be created on the xfs data device (e.g. ext4, xfs realtime, etc.)

Signed-off-by: Darrick J. Wong <[e-mail]>
---
 tests/generic/204 |    8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

Comments

Christoph Hellwig Sept. 17, 2020, 7:56 a.m. UTC | #1

On Mon, Sep 14, 2020 at 06:44:18PM -0700, Darrick J. Wong wrote:
> From: Darrick J. Wong <[e-mail]>
> 
> This test has been on and off my bad list for many years due to the fact
> that it will spew potentially millions of "No space left on device"
> errors if the file count calculations are wrong.  The calculations
> should be correct for the XFS data device, but they don't apply to other
> filesystems.
> 
> Therefore, filter out the ENOSPC messages when the files are not going
> to be created on the xfs data device (e.g. ext4, xfs realtime, etc.)

Should this move to an xfs specific test instead?

Darrick J. Wong Sept. 17, 2020, 4:02 p.m. UTC | #2

On Thu, Sep 17, 2020 at 08:56:35AM +0100, Christoph Hellwig wrote:
> On Mon, Sep 14, 2020 at 06:44:18PM -0700, Darrick J. Wong wrote:
> > From: Darrick J. Wong <[e-mail]>
> > 
> > This test has been on and off my bad list for many years due to the fact
> > that it will spew potentially millions of "No space left on device"
> > errors if the file count calculations are wrong.  The calculations
> > should be correct for the XFS data device, but they don't apply to other
> > filesystems.
> > 
> > Therefore, filter out the ENOSPC messages when the files are not going
> > to be created on the xfs data device (e.g. ext4, xfs realtime, etc.)
> 
> Should this move to an xfs specific test instead?

I'm on the fence about that, but probably.  I've though that generic/
can have a test that formats a small fs and fills it with files until it
hits ENOSPC, and this test (with its weird calculations) can move to xfs/.

But I haven't been around long enough to know if there's a specific
reason why we calculate the number of files to create?  Is this test
really a regression test for some long-ago bug?  Or that weird noalloc
dir update mode thing that we ripped out last year?

--D

Patch

diff --git a/tests/generic/204 b/tests/generic/204
index 349f5eff..7250c00a 100755
--- a/tests/generic/204
+++ b/tests/generic/204
@@ -76,9 +76,13 @@  files=$((space / (direntlen + isize + dbsize)))
 echo files $files, resvblks $resv_blks >> $seqres.full
 _scratch_resvblks $resv_blks >> $seqres.full 2>&1
 
+filter() {
+	test $FSTYP != xfs && sed -e '/No space left on device/d'
+}
+
 for i in `seq -w 1 $files`; do
-    echo -n > $SCRATCH_MNT/$i
-    echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > $SCRATCH_MNT/$i
+	(echo -n > $SCRATCH_MNT/$i;
+	 echo XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX > $SCRATCH_MNT/$i) 2>&1 | filter
 done
 
 # success, all done