| Message ID | 151314505158.18893.11894289091110903029.stgit@magnolia (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Tue, Dec 12, 2017 at 10:04:11PM -0800, Darrick J. Wong wrote: > From: Darrick J. Wong <darrick.wong@oracle.com> > > 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.... Cheers, Dave.
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@oracle.com> > > > > 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... ...unless a better solution to count the number of dirs/files and compare to whatever xfsrestore says? --D > Cheers, > > Dave. > -- > Dave Chinner > david@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@oracle.com> > > > > > > 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.
On Thu, Dec 14, 2017 at 09:45:53AM +1100, Dave Chinner wrote: > 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@oracle.com> > > > > > > > > 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? The operations themselves are deterministic, but adding the two commands for clone & dedupe changed the size of the ops table, which means that fsstress pursues a different sequence of operations for a given nproc and seed input. Furthermore, the outcome of the operations will differ depending on whether or not the xfs supports reflink, because a clonerange that fails with EOPNOTSUPP causes the commands' frequency to be zeroed in the command table. --D > > ...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 > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe fstests" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Dec 13, 2017 at 03:17:45PM -0800, Darrick J. Wong wrote: > On Thu, Dec 14, 2017 at 09:45:53AM +1100, Dave Chinner wrote: > > 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@oracle.com> > > > > > > > > > > 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? > > The operations themselves are deterministic, but adding the two commands > for clone & dedupe changed the size of the ops table, which means that > fsstress pursues a different sequence of operations for a given nproc > and seed input. Furthermore, the outcome of the operations will differ > depending on whether or not the xfs supports reflink, because a > clonerange that fails with EOPNOTSUPP causes the commands' frequency to > be zeroed in the command table. Ah, ok. So it's the dynamic nature of newly supported operations that causes the problems for this test, not that the options arei supported. Seems reasonable just to disable them for these tests, then. -Dave.
diff --git a/tests/xfs/068 b/tests/xfs/068 index 7151e28..119b204 100755 --- a/tests/xfs/068 +++ b/tests/xfs/068 @@ -44,7 +44,9 @@ _supported_fs xfs _supported_os Linux _create_dumpdir_stress_num 4096 -_do_dump_restore +# Fancy filtering here because fsstress doesn't always create the +# same number of files (depending on the fs geometry) +_do_dump_restore | sed -e 's/xfsrestore: [0-9]* directories and [0-9]* entries/xfsrestore: XXX directories and YYY entries/g' # success, all done exit diff --git a/tests/xfs/068.out b/tests/xfs/068.out index fa3a552..f53c555 100644 --- a/tests/xfs/068.out +++ b/tests/xfs/068.out @@ -22,7 +22,7 @@ xfsrestore: session id: ID xfsrestore: media ID: ID xfsrestore: searching media for directory dump xfsrestore: reading directories -xfsrestore: 383 directories and 1335 entries processed +xfsrestore: XXX directories and YYY entries processed xfsrestore: directory post-processing xfsrestore: restoring non-directory files xfsrestore: restore complete: SECS seconds elapsed