On Tue, Aug 01, 2023 at 02:55:29PM +0800, Qu Wenruo wrote: > [BUG] > Sometimes test case btrfs/276 would fail with extra number of extents: > > - output mismatch (see /opt/xfstests/results//btrfs/276.out.bad) > --- tests/btrfs/276.out 2023-07-19 07:24:07.000000000 +0000 > +++ /opt/xfstests/results//btrfs/276.out.bad 2023-07-28 04:15:06.223985372 +0000 > @@ -1,16 +1,16 @@ > QA output created by 276 > wrote 17179869184/17179869184 bytes at offset 0 > XXX Bytes, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec) > -Number of non-shared extents in the whole file: 131072 > +Number of non-shared extents in the whole file: 131082 > Create a snapshot of 'SCRATCH_MNT' in 'SCRATCH_MNT/snap' > -Number of shared extents in the whole file: 131072 > ... > (Run 'diff -u /opt/xfstests/tests/btrfs/276.out /opt/xfstests/results//btrfs/276.out.bad' to see the entire diff) > > [CAUSE] > The test case uses golden output to record the number of total extents > of a 16G file. > > This is not reliable as we can have writeback happen halfway, resulting > smaller extents thus slightly more extents. > > With a VM with 4G memory, I have a chance around 1/10 hitting this > false alert. > > [FIX] > Instead of using golden output, we allow a slight (5%) float in the > number of extents, and move the 131072 (and 131072 - 16) from golden > output, so even if we have a slightly more extents, we can still pass > the test. > > Signed-off-by: Qu Wenruo <wqu@xxxxxxxx> Reviewed-by: Josef Bacik <josef@xxxxxxxxxxxxxx> Thanks, Josef
