On Wed, Dec 13, 2017 at 02:23:52PM -0800, Darrick J. Wong wrote:

On Thu, Dec 14, 2017 at 09:20:46AM +1100, Dave Chinner wrote:

quoted

On Tue, Dec 12, 2017 at 10:04:11PM -0800, Darrick J. Wong wrote:

quoted

From: Darrick J. Wong <redacted>

In this test we use fsstress to create some number of files and then
exercise xfsdump/xfsrestore on them.  Depending on the fsstress config
we may end up with a different number of files than is hardcoded in the
golden output (particularly after adding reflink support to fsstress)
and thereby fail the test.  Since we're not really testing how many
files fsstress can create, just turn the counts into XXX/YYY.

Hmmmm. those numbers were in the golden output specifically because
fsstress is supposed to be deterministic for a given random seed.
What it is supposed to be testing is that xfsdump actually dumped
all the files that were created, and xfs-restore was able to process
them all. If either barf on a file, they'll silently skip it, and
the numbers won't come out properly.

The typical class of bug this test finds is bulkstat iteration
problems - if bulkstat misses an inode it shouldn't, then the
xfsrestore numbers come out wrong. By making the data set
non-deterministic and not checking the numbers, we end up losing the
ability of this test to check bulkstat iteration and dump/restore
completeness....

Ah, fun.  Ok, in that case I think the correct fix for this problem is
to turn off clonerange/deduperange in the fsstress command line so that
we get back to deterministic(?) counts...

Why aren't the clonerange/deduperange operations deterministic?
Shouldn't these always do the same thing from the POV of
xfsdump/restore?

...unless a better solution to count the number of dirs/files and compare
to whatever xfsrestore says?

Haven't looked recently, but there were reasons for doing it this
way that I don't recall off the top of my head...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com