[2/2] xfs/068: Add fsstress generated file count to golden output
diff mbox series

Message ID 20190124083310.25928-2-amir73il@gmail.com
State New
Headers show
Series
  • [1/2] common/dump: do not override test cleanup trap
Related show

Commit Message

Amir Goldstein Jan. 24, 2019, 8:33 a.m. UTC
This test has the number of files/dirs created by fsstress 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.

Since the golden output includes only the file count after dump/restore,
add also the file count before dump/restore so developers are less
likely to forget to check the validity of golden output before commiting
the change.

For some reason the file count reported by xfsrestore has one directory
more than the file count reported by 'find'. I did not investigate why
that is, but did verify that this was the same with the original test
fsstress ops (i.e. without the added ops
insert/mread/mwrite/aread/awrite/readv/writev).

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
---
 common/dump       | 7 +++++++
 tests/xfs/068     | 1 +
 tests/xfs/068.out | 1 +
 3 files changed, 9 insertions(+)

Comments

Eryu Guan Jan. 27, 2019, 5:02 a.m. UTC | #1
[I'm sorry that I've been absent from the discussion entirely.. I was
busy with other tasks recently.]

On Thu, Jan 24, 2019 at 10:33:10AM +0200, Amir Goldstein wrote:
> This test has the number of files/dirs created by fsstress hardcoded
> in golden output.

This leads me to wonder if we could remove the hardcoded dir/entries
number from the golden output and verify the counts on the fly? i.e. we
count the dir/entries numbers that fsstress created and compare them
with the numbers xfsrestore reports. So we don't have to worry about new
ops in fsstress and xfs configurations.

But for now, I'd like to take Zorro's v3 patch, which follows Dave's
suggestion. And I've verified that the restored dir/entires counts
matched what fsstress created (so previously added
insert/mread/mwrite etc. ops didn't break xfs/068 either).

> 
> 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.
> 
> Since the golden output includes only the file count after dump/restore,
> add also the file count before dump/restore so developers are less
> likely to forget to check the validity of golden output before commiting
> the change.
> 
> For some reason the file count reported by xfsrestore has one directory
> more than the file count reported by 'find'. I did not investigate why

I haven't looked at the xfsrestore code yet, but I guess it's because
xfsrestore counts the '$SCRATCH_MNT/restoredir' as one entry processed
as well.

Thanks,
Eryu

> that is, but did verify that this was the same with the original test
> fsstress ops (i.e. without the added ops
> insert/mread/mwrite/aread/awrite/readv/writev).
> 
> Signed-off-by: Amir Goldstein <amir73il@gmail.com>
> ---
>  common/dump       | 7 +++++++
>  tests/xfs/068     | 1 +
>  tests/xfs/068.out | 1 +
>  3 files changed, 9 insertions(+)
> 
> diff --git a/common/dump b/common/dump
> index 47d14601..23f42216 100644
> --- a/common/dump
> +++ b/common/dump
> @@ -1515,6 +1515,13 @@ _check_quota_file()
>     _check_quota 'xfsdump_quotas' 'xfsdump_quotas_group' 'xfsdump_quotas_proj'
>  }
>  
> +_count_dumpdir_files()
> +{
> +	local ndirs=$(find $dump_dir -type d | wc -l)
> +	local nents=$(find $dump_dir | wc -l)
> +
> +	echo "Created $ndirs directories and $nents entries"
> +}
>  
>  # make sure this script returns success
>  /bin/true
> diff --git a/tests/xfs/068 b/tests/xfs/068
> index 95a8cd12..ffc293bd 100755
> --- a/tests/xfs/068
> +++ b/tests/xfs/068
> @@ -28,6 +28,7 @@ _supported_fs xfs
>  _supported_os Linux
>  
>  _create_dumpdir_stress_num 4096
> +_count_dumpdir_files
>  _do_dump_restore
>  
>  # success, all done
> diff --git a/tests/xfs/068.out b/tests/xfs/068.out
> index fa3a5523..61cbbfa4 100644
> --- a/tests/xfs/068.out
> +++ b/tests/xfs/068.out
> @@ -4,6 +4,7 @@ Creating directory system to dump using fsstress.
>  -----------------------------------------------
>  fsstress : -f link=10 -f creat=10 -f mkdir=10 -f truncate=5 -f symlink=10
>  -----------------------------------------------
> +Created 382 directories and 1334 entries
>  xfsdump|xfsrestore ...
>  xfsdump  -s DUMP_SUBDIR - SCRATCH_MNT | xfsrestore  - RESTORE_DIR
>  xfsrestore: using file dump (drive_simple) strategy
> -- 
> 2.17.1
>
Amir Goldstein Jan. 27, 2019, 8 a.m. UTC | #2
On Sun, Jan 27, 2019 at 7:02 AM Eryu Guan <guaneryu@gmail.com> wrote:
>
> [I'm sorry that I've been absent from the discussion entirely.. I was
> busy with other tasks recently.]
>
> On Thu, Jan 24, 2019 at 10:33:10AM +0200, Amir Goldstein wrote:
> > This test has the number of files/dirs created by fsstress hardcoded
> > in golden output.
>
> This leads me to wonder if we could remove the hardcoded dir/entries
> number from the golden output and verify the counts on the fly? i.e. we
> count the dir/entries numbers that fsstress created and compare them
> with the numbers xfsrestore reports. So we don't have to worry about new
> ops in fsstress and xfs configurations.
>

posted v2 with a slightly different approach:
count the dir/entries numbers that fsstress created and compare them
with the *actual* numbers xfsrestore created instead of the numbers that
xfsrestore reports.

Sure, this removes test coverage for the accuracy of the report, but
that was really never the intention of the test and the report is really
wrong! (off by one dir from actual restored).

If someone really cares about validating the accuracy of xfsrestore report
in that test, that by all means, let someone read into xfsrestore and figure
out what the one directory stands for and either fix xfsrestore or work that
quirk into the test. As can be inferred, that someone is not going to be me.

Thanks,
Amir.

Patch
diff mbox series

diff --git a/common/dump b/common/dump
index 47d14601..23f42216 100644
--- a/common/dump
+++ b/common/dump
@@ -1515,6 +1515,13 @@  _check_quota_file()
    _check_quota 'xfsdump_quotas' 'xfsdump_quotas_group' 'xfsdump_quotas_proj'
 }
 
+_count_dumpdir_files()
+{
+	local ndirs=$(find $dump_dir -type d | wc -l)
+	local nents=$(find $dump_dir | wc -l)
+
+	echo "Created $ndirs directories and $nents entries"
+}
 
 # make sure this script returns success
 /bin/true
diff --git a/tests/xfs/068 b/tests/xfs/068
index 95a8cd12..ffc293bd 100755
--- a/tests/xfs/068
+++ b/tests/xfs/068
@@ -28,6 +28,7 @@  _supported_fs xfs
 _supported_os Linux
 
 _create_dumpdir_stress_num 4096
+_count_dumpdir_files
 _do_dump_restore
 
 # success, all done
diff --git a/tests/xfs/068.out b/tests/xfs/068.out
index fa3a5523..61cbbfa4 100644
--- a/tests/xfs/068.out
+++ b/tests/xfs/068.out
@@ -4,6 +4,7 @@  Creating directory system to dump using fsstress.
 -----------------------------------------------
 fsstress : -f link=10 -f creat=10 -f mkdir=10 -f truncate=5 -f symlink=10
 -----------------------------------------------
+Created 382 directories and 1334 entries
 xfsdump|xfsrestore ...
 xfsdump  -s DUMP_SUBDIR - SCRATCH_MNT | xfsrestore  - RESTORE_DIR
 xfsrestore: using file dump (drive_simple) strategy