@@ -47,16 +47,17 @@ _scratch_mount
# create files
i=1;
-while [ $i -lt 1000 ]
+t=`date +%s`
+while [ $i -lt 5000 ]
do
file=$SCRATCH_MNT/$i
- xfs_io -f -c "pwrite -b 32k -S 0xff 0 32k" $file > /dev/null
+ xfs_io -f -c "pwrite -b 8k -S 0xff 0 8k" $file > /dev/null
if [ $? -ne 0 ]
then
echo error creating/writing file $file
exit
fi
- xfs_io -c "truncate 64k" $file > /dev/null
+ xfs_io -c "truncate 16k" $file > /dev/null
if [ $? -ne 0 ]
then
echo error truncating file $file
@@ -64,9 +65,13 @@ do
fi
let i=$i+1
done
+t=$((`date +%s` - $t))
# give the system a chance to write something out
-sleep 10
+if [ $t -lt 60 ]
+then
+ sleep $((60 - $t))
+fi
src/godown $SCRATCH_MNT
@@ -82,7 +87,7 @@ _scratch_mount
# check file size and contents
i=1;
-while [ $i -lt 1000 ]
+while [ $i -lt 5000 ]
do
file=$SCRATCH_MNT/$i
# if file does not exist, the create was not logged, skip it
According to lots of our testing results, this case always can't write any files out until this case run over. This is not expected test condition. But when I run this case on a very poor performance machine, or run with other I/O stress, some file can write out. So I think the stress of this case is not enough, and create more files or sleep more time will be helpful. I choose the former. Because if only increase sleep time, maybe cause all files be write out, nothing be cached. There're many other conditions maybe affect this problem, include "RAM size", "disk size", "vm.dirty_expire_centisecs", "vm.dirty_writeback_centisecs" and so on... I have to say "yes, the machine performance will affect test, but according to my experiment, their effect isn't so much." My test machine is 16G RAM, 20G test partation. I changed 16G ram to 2G, 20G disk to 2G, and create 3000 files in case, but useless. I also try to change vm.dirty_expire_centisecs and vm.dirty_writeback_centisecs, big change, but still useless. So I think create more files to increase the stress is the most useful method. From my test, I find 60s is an enough time. So I try to make sure this case keep running 60s. Signed-off-by: Zorro Lang <zlang@redhat.com> --- Hi, As I said above, please check the below patch. I can't sure this's the best way. So if someone learn about XFS very well, please help to review. I find this problem from a bug which eguan@redhat.com has sent patch: common: fix _count_extents and _count_holes We have ran xfstests thousands of times, but nearly can't trigger this bug, until I ran xfstests with fsstress. So I think the stress of generic/046 is not enough. I think Lachlan McIlroy is the author of this case, but I feel his email lmcilroy@redhat.com already invalid. So I can't cc him. Thanks, Zorro Lang tests/generic/046 | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-)