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: > > On Tue, Dec 12, 2017 at 10:04:11PM -0800, Darrick J. Wong wrote: > > > From: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > > > > > > 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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
