On Sun, Nov 24, 2024 at 09:20:29PM -0800, Christoph Hellwig wrote: > On Sun, Nov 24, 2024 at 09:16:39PM -0800, Darrick J. Wong wrote: > > On Sun, Nov 24, 2024 at 09:14:43PM -0800, Christoph Hellwig wrote: > > > On Fri, Nov 22, 2024 at 08:52:48AM -0800, Darrick J. Wong wrote: > > > > +# with ENOSPC for example. However, XFS will sometimes run out of space. > > > > +_reflink $SCRATCH_MNT/bar $SCRATCH_MNT/foo >>$seqres.full 2> $tmp.err > > > > +cat $tmp.err > > > > +test "$FSTYP" = "xfs" && grep -q 'No space left on device' $tmp.err && \ > > > > + _notrun "ran out of space while cloning" > > > > > > Should this simply be unconditional instead of depend on XFS? > > > > Felipe said no: > > https://lore.kernel.org/fstests/CAL3q7H5KjvXsXzt4n0XP1FTUt=A5cKom7p+dGD6GG-iL7CyDXQ@xxxxxxxxxxxxxx/ > > Hmm. Being able to totally fill the fs without ENOSPC seems odd. > Maybe we need to figure out a way to scale down the size for the generic > test and have a separate one for the XFS ENOSPC case? Not a huge fan > of that, but the current version also seems odd. Yeah, I definitely need to write a fstest that can trip this bug on smaller fsblock filesystems. In the meantime, this one should not fail just because xfs runs out of space before the point where this test would have thought that would happen; and then xfs_io spews an error message into the golden output. Though if this is really a test that computes when *btrfs* would run out of space and drives towards that point just to see if ENOSPC does /not/ come out of the kernel, then maybe this belongs in tests/btrfs/ ? --D
