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@xxxxxxxxxx> > > > > 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
