Commit Graph

5 Commits

Author SHA1 Message Date
Amir Goldstein a70fb7335c xfs/068: Verify actual file count instead of reported file count
This test has the number of files/dirs created by xfsrestore hardcoded
in golden output.

When fsstress is added new ops, the number of files/dirs created with
the same random seed changes and this regularly breaks this test,
so when new fsstress ops are added they should be either added to the
dump test blacklist or golden output of this test needs to be ammended
to reflect the change.

The golden output includes only the file count reported by xfsrestore
and test does not even verify that this is the correct file count.
Instead, leave the golden output neutral and explicitly verify that
file count before and after the test are the same.

With this change, the test becomes agnostic to fsstress ops and we
could also stop blacklisting clone/dedup/copy ops if we want.

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-02-10 19:14:56 +08:00
Zorro Lang d613bee203 xfs/068: update golden output due to new operations in fsstress
I added some new operatoins to fsstress, and it changed the total
number of test operstions.

xfs/068 use a fixed seed (-s) and number of operations (-n) to run
fsstress, to get fixed number of files and directories. Due to my
patches break these fixed things, so update its expected result in
golden image.

Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
2017-07-28 18:53:51 +08:00
Zorro Lang 5d36d8585a xfs/068: update golden output due to new operations in fsstress
xfs/068 use a fixed seed (-s) and number of operations (-n) to run
fsstress, to get fixed number of files and directories. But new
operations of fsstress will break this "fixed number". So update
it, after fsstress get new operations.

Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
2017-03-29 15:07:56 +08:00
Eric Sandeen 155cf517b0 xfs/068: fix expected output file for proper restore output
Oh my, I did a very bad thing - I wrote a new test to
check for xfsdump regressions, but did not create the
.out file with a known-good kernel.

This matches output from older, stable kernels, and is the
proper expected output.  Sorry about that!

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-11-10 18:06:23 +11:00
Eric Sandeen 481c28f52f xfs: test larger dump/restore to/from file
This test creates a large-ish directory structure using
fsstress, and does a dump/restore to make sure we dump
all the files.

Without the fix for the regression caused by:
c7cb51d xfs: fix error handling at xfs_inumbers

we will see failures like:

    -xfsrestore: 486 directories and 1590 entries processed
    +xfsrestore: 30 directories and 227 entries processed

as it fails to process all inodes.

I think that existing tests have a much smaller set of files,
and so don't trip the bug.

I don't do a file-by-file comparison here, because for some
reason the diff output gets garbled; this test only checks
that we've dumped & restored the correct number of files.

Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
2014-10-14 22:59:39 +11:00