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

Darrick J. Wong
2020-09-17T16:04:52Z

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 <darrick.wong@oracle.com>
> >
> > 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