Ever since commit
7e2a19504 ("ls -l reports different file size
depending on platform and user.") xfs/066 has been running stat on
the dump/restore directory instead of the large file that the test
is checking can be dumped and restored correctly. IOWs, it's not
been checking the correct thing for almost 10 years.
This test fails on CRC enabled filesystems because the shortform
directory entry size is different (an extra byte for the filetype
filed), and this is where tracking down the failure has lead me.
Fix this by using the correct target file, and improve it by dumping
an md5sum of the source and target files to ensure they contain the
same data.
Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>
_create_dumpdir_largefile
echo "ls dumpdir/largefile"
-stat $dump_dir | _my_stat_filter
+stat $dump_dir/largefile | _my_stat_filter
+md5sum $dump_dir/largefile |_filter_scratch
_do_dump_file
_do_restore_file
echo "ls restoredir/largefile"
-stat $restore_dir/$dump_sdir | _my_stat_filter
+stat $restore_dir/$dump_sdir/largefile | _my_stat_filter
+md5sum $restore_dir/$dump_sdir/largefile |_filter_scratch
# success, all done
status=0
10+0 records in
10+0 records out
ls dumpdir/largefile
-22 largefile
+4294967307 largefile
+e2664609cb95c2215732cf4e71e45017 SCRATCH_MNT/dumpdir/largefile
Dumping to file...
xfsdump -f DUMP_FILE -M stress_tape_media -L stress_066 SCRATCH_MNT
xfsdump: using file dump (drive_simple) strategy
xfsrestore: restore complete: SECS seconds elapsed
xfsrestore: Restore Status: SUCCESS
ls restoredir/largefile
-22 largefile
+4294967307 largefile
+e2664609cb95c2215732cf4e71e45017 SCRATCH_MNT/restoredir/dumpdir/largefile