FIO is very flexible io generator, i would call it IO swiss knife.
Currently we have tonnes of hardcoded application which reproduces
some predefined scenario. This approach has obvious dissadvantages
1) Lack of flexability: once written it is hard to modify it in future
2) Code base is large, many routines written again and again
At the same time add new fio based tast is just add simle INI file.
This greatly simplify code review. I do beleve that some day we will
replace most of hardcoded io binaries with fio.
Signed-off-by: Dmitry Monakhov <[email protected]>
---
.gitmodules | 3 +++
common.config | 3 +++
src/Makefile | 8 +++++---
src/aio-dio-regress/Makefile | 4 ++--
src/fio | 1 +
5 files changed, 14 insertions(+), 5 deletions(-)
create mode 100644 .gitmodules
create mode 160000 src/fio
diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 0000000..f0481ea
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule "src/fio"]
+ path = src/fio
+ url = git://git.kernel.dk/fio.git
diff --git a/common.config b/common.config
index 7bed1c5..25cddb4 100644
--- a/common.config
+++ b/common.config
@@ -138,6 +138,9 @@ export DF_PROG="`set_prog_path df`"
[ "$DF_PROG" = "" ] && _fatal "df not found"
[ "$HOSTOS" = "Linux" ] && export DF_PROG="$DF_PROG -T"
+export FIO_PROG="`set_prog_path $PWD/src/fio/fio`"
+[ "$FIO_PROG" = "" ] && _fatal "fio not found"
+
export XFS_LOGPRINT_PROG="`set_prog_path xfs_logprint`"
export XFS_REPAIR_PROG="`set_prog_path xfs_repair`"
export XFS_CHECK_PROG="`set_prog_path xfs_check`"
diff --git a/src/Makefile b/src/Makefile
index 67250ee..255bdd4 100644
--- a/src/Makefile
+++ b/src/Makefile
@@ -52,16 +52,18 @@ LLDLIBS += $(LIBGDBM)
endif
ifeq ($(HAVE_AIO), true)
-SUBDIRS += aio-dio-regress
+SUBDIRS += aio-dio-regress \
+ fio
+
endif
CFILES = $(TARGETS:=.c)
LDIRT = $(TARGETS)
-default: depend $(TARGETS) $(SUBDIRS)
+default: .depend $(TARGETS) $(SUBDIRS)
-depend: .dep
+.depend: .dep
include $(BUILDRULES)
diff --git a/src/aio-dio-regress/Makefile b/src/aio-dio-regress/Makefile
index 79dd55d..fcead9a 100644
--- a/src/aio-dio-regress/Makefile
+++ b/src/aio-dio-regress/Makefile
@@ -8,9 +8,9 @@ LDIRT = $(TARGETS)
LLDLIBS = -laio -lpthread
-default: depend $(TARGETS)
+default: .depend $(TARGETS)
-depend: .dep
+.depend: .dep
include $(BUILDRULES)
diff --git a/src/fio b/src/fio
new file mode 160000
index 0000000..e12d280
--- /dev/null
+++ b/src/fio
@@ -0,0 +1 @@
+Subproject commit e12d2800f811cb64d376cfdaed9a1257f3fa9c99
--
1.7.7.6
Most stress test has probable behaviour, the longer test run the
larger corner cases will be cover. It is reasonable to allow
user to provide some sort of system load factor.
This patch introduce two global variables
LOAD_FACTOR: Usually means factor number of running tasks
TIME_FACTOR: Usually means factor of run time, or number of operations
If not speficied both variables defined to 1, so original behaviour
preserved.
TODO: Change all stress tests to use this variables
Signed-off-by: Dmitry Monakhov <[email protected]>
---
common.config | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/common.config b/common.config
index 25cddb4..a24b915 100644
--- a/common.config
+++ b/common.config
@@ -255,5 +255,13 @@ if [ ! -z "$SCRATCH_MNT" -a ! -d "$SCRATCH_MNT" ]; then
exit 1
fi
+if [ -z "$LOAD_FACTOR" ]; then
+ LOAD_FACTOR=1
+fi
+
+if [ -z "$TIME_FACTOR" ]; then
+ TIME_FACTOR=1
+fi
+
# make sure this script returns success
/bin/true
--
1.7.7.6
Run DIO, fallocate and punch_hole threads on a common file in parallel.
If race exist old dio request may rewrite punched block after it was
allocated to another file, we will catch that by verifying blocks content.
Signed-off-by: Dmitry Monakhov <[email protected]>
---
287 | 155 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
group | 1 +
2 files changed, 156 insertions(+), 0 deletions(-)
create mode 100755 287
diff --git a/287 b/287
new file mode 100755
index 0000000..40e096e
--- /dev/null
+++ b/287
@@ -0,0 +1,155 @@
+#! /bin/bash
+# FSQA Test No. 287
+#
+# Test various races AIO/DIO vs fallocate/punch_hole
+#
+#-----------------------------------------------------------------------
+# Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+#-----------------------------------------------------------------------
+#
+# creator
[email protected]
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1 # failure is the default!
+trap "rm -f $tmp.*; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+run_check()
+{
+ echo "# $@" >> $seq.full 2>&1
+ "$@" >> $seq.full 2>&1 || _fail "failed: '$@'"
+}
+
+
+NUM_JOBS=$((4*LOAD_FACTOR))
+BLK_DEV_SIZE=`blockdev --getsz $SCRATCH_DEV`
+if [ $((BLK_DEV_SIZE)) -gt 1048576 ]
+then
+ BLK_DEV_SIZE=1048576
+fi
+FS_SIZE=$((BLK_DEV_SIZE * 512))
+
+cat >$tmp-$seq.fio <<EOF
+###########
+# $seq test fio activity
+# Run DIO, fallocate and punch_hole threads on a single in parallel
+#
+# If race exist old dio request may rewrite punched block after it was
+# allocated to another file, we will catch that by verifying blocks content
+#
+[global]
+directory=${SCRATCH_MNT}
+filesize=${FS_SIZE}
+size=999G
+continue_on_error=write
+ignore_error=,ENOSPC
+error_dump=0
+
+create_on_open=1
+fallocate=none
+exitall=1
+
+## Perform direct aio, to files which may be truncated
+## by external task
+[direct_aio_raicer]
+ioengine=libaio
+iodepth=128*${LOAD_FACTOR}
+bs=128k
+direct=1
+numjobs=${NUM_JOBS}
+rw=randwrite
+runtime=100*${TIME_FACTOR}
+time_based
+filename=racer
+
+# Run falloc and punch_hole threads in parallel
+# After activity file will be highly fragmented
+[falloc_raicer]
+ioengine=falloc
+runtime=100*${TIME_FACTOR}
+iodepth=1
+bssplit=128k/80:512k/10:32k/10
+rw=randwrite
+numjobs=1
+filename=racer
+
+[punch_hole_raicer]
+ioengine=falloc
+runtime=100*${TIME_FACTOR}
+bs=4k
+time_based=10
+rw=randtrim
+numjobs=2
+filename=racer
+time_based
+
+# Verifier thread continiously write to newly allcated blocks
+# and veryfy written content
+[aio-dio-verifier]
+ioengine=libaio
+iodepth=128*${LOAD_FACTOR}
+numjobs=1
+verify=crc32c-intel
+verify_fatal=1
+verify_dump=1
+verify_backlog=1024
+verify_async=4
+verifysort=1
+direct=1
+bs=4k
+rw=randwrite
+filename=aio-dio-verifier
+EOF
+
+_workout()
+{
+ echo ""
+ echo "Run fio with random aio-dio pattern"
+ echo ""
+ cat $tmp-$seq.fio >> $seq.full
+ run_check $FIO_PROG $tmp-$seq.fio >> $seq.full
+}
+
+# real QA test starts here
+_supported_fs generic
+_supported_os Linux
+_need_to_be_root
+_require_scratch
+
+_scratch_mkfs_sized $FS_SIZE >> $seq.full 2>&1
+_scratch_mount
+
+if ! _workout; then
+ umount $SCRATCH_DEV 2>/dev/null
+ exit
+fi
+
+if ! _scratch_unmount; then
+ echo "failed to umount"
+ status=1
+ exit
+fi
+_check_scratch_fs
+status=$?
+exit
diff --git a/group b/group
index 2469f80..37f3256 100644
--- a/group
+++ b/group
@@ -405,3 +405,4 @@ deprecated
284 auto
285 auto dump quota quick
286 auto rw enospc aio
+287 auto rw enospc aio prealloc
--
1.7.7.6
Perform various regression tests for ext4defrag subsystem
Test1: Defragment file while other task does direct AIO
Test2: Perform defragmentation on file under buffered AIO
while third task does direct AIO to donor file
Test3: Two defrag tasks use common donor file.
Test4: Stress defragmentation. Several threads pefrorm
fragmentation at random position use inplace=1 will
allocate and free blocks inside defrag event improve
load pressure.
This test known to caught most known e4defrag bugs.
Signed-off-by: Dmitry Monakhov <[email protected]>
---
288 | 277 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
288.out | 4 +
group | 1 +
3 files changed, 282 insertions(+), 0 deletions(-)
create mode 100755 288
create mode 100644 288.out
diff --git a/288 b/288
new file mode 100755
index 0000000..c972f88
--- /dev/null
+++ b/288
@@ -0,0 +1,277 @@
+#! /bin/bash
+# FSQA Test No. 288
+#
+# Ext4 defragmentatio stress test
+#
+#-----------------------------------------------------------------------
+# Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+#-----------------------------------------------------------------------
+#
+# creator
[email protected]
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1 # failure is the default!
+trap "rm -f $tmp.*; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+run_check()
+{
+ echo "# $@" >> $seq.full 2>&1
+ "$@" >> $seq.full 2>&1 || _fail "failed: '$@'"
+}
+
+
+NUM_JOBS=$((4*LOAD_FACTOR))
+BLK_DEV_SIZE=`blockdev --getsz $SCRATCH_DEV`
+# We need space for 8 files
+FILE_SIZE=$((BLK_DEV_SIZE * (512 /12)))
+
+cat >$tmp-$seq.fio <<EOF
+# Various e4defrag regression tests
+[global]
+ioengine=ioe_e4defrag
+iodepth=1
+directory=${SCRATCH_MNT}
+filesize=${FILE_SIZE}
+size=999G
+buffered=0
+fadvise_hint=0
+group_reporting
+
+#################################
+# Test1
+# Defragment file while other task does direct io
+
+# Continious sequential defrag activity
+[defrag-4k]
+ioengine=e4defrag
+iodepth=1
+bs=128k
+donorname=test1.def
+filename=test1
+inplace=0
+rw=write
+numjobs=1
+runtime=30
+time_based
+
+# Verifier
+[aio-dio-verifier]
+ioengine=libaio
+iodepth=128*${LOAD_FACTOR}
+numjobs=1
+verify=crc32c-intel
+verify_fatal=1
+verify_dump=1
+verify_backlog=1024
+verify_async=1
+verifysort=1
+direct=1
+bs=64k
+rw=randwrite
+filename=test1
+runtime=30
+time_based
+
+##########################################
+# Test2
+# Perform defragmentation on file under buffered io
+# while third task does direct io to donor file
+#
+# Continious sequential defrag activity
+[defrag-4k]
+stonewall
+ioengine=e4defrag
+iodepth=1
+bs=128k
+donorname=test2.def
+filename=test2
+inplace=0
+rw=write
+numjobs=1
+runtime=30
+time_based
+
+# Run DIO/AIO for donor file
+[donor-file-fuzzer]
+ioengine=libaio
+iodepth=128*${LOAD_FACTOR}
+numjobs=1
+verify=0
+direct=1
+bs=64k
+rw=randwrite
+filename=test2.def
+runtime=30
+time_based
+
+# Verifier thread
+[aio-dio-verifier]
+ioengine=libaio
+iodepth=128*${LOAD_FACTOR}
+numjobs=1
+verify=crc32c-intel
+verify_fatal=1
+verify_dump=1
+verify_backlog=1024
+verify_async=1
+verifysort=1
+buffered=1
+bs=64k
+rw=randrw
+filename=test2
+runtime=30
+time_based
+
+#################################
+# Test3
+# Two defrag tasks use common donor file
+
+[defrag-1]
+ioengine=e4defrag
+iodepth=1
+bs=128k
+donorname=test3.def
+filename=test31
+inplace=0
+rw=write
+numjobs=1
+runtime=30
+time_based
+
+[defrag-2]
+ioengine=e4defrag
+iodepth=1
+bs=128k
+donorname=test3.def
+filename=test32
+inplace=0
+rw=write
+numjobs=1
+runtime=30
+time_based
+
+[aio-dio-verifier-1]
+ioengine=libaio
+iodepth=128*${LOAD_FACTOR}
+numjobs=1
+verify=crc32c-intel
+verify_fatal=1
+verify_dump=1
+verify_backlog=1024
+verify_async=1
+verifysort=1
+direct=1
+bs=64k
+rw=write
+filename=test31
+runtime=30
+time_based
+
+[aio-buffer-verifier-2]
+ioengine=libaio
+numjobs=1
+verify=crc32c-intel
+verify_fatal=1
+verify_dump=1
+verify_backlog=1024
+verify_async=1
+verifysort=1
+buffered=1
+bs=64k
+rw=randrw
+filename=test32
+runtime=30
+time_based
+
+#################################
+# Test4
+# Stress test defragmentation
+# Several threads pefrorm defragmentatin at random position
+# use inplace=1 will allocate and free blocks inside defrag event
+# improve load pressure
+[defrag-fuzzer]
+ioengine=e4defrag
+iodepth=1
+bs=8k
+donorname=test4.def
+filename=test4
+inplace=1
+rw=randwrite
+numjobs=4*${LOAD_FACTOR}
+runtime=30
+time_based
+
+[aio-dio-verifier]
+ioengine=libaio
+iodepth=128
+iomem_align=4k
+numjobs=1
+verify=crc32c-intel
+verify_fatal=1
+verify_dump=1
+verify_backlog=1024
+verify_async=1
+verifysort=1
+direct=1
+bs=64k
+rw=write
+filename=test4
+runtime=30
+time_based
+
+EOF
+
+_workout()
+{
+ echo ""
+ echo " Start defragment activity "
+ echo ""
+ cat $tmp-$seq.fio >> $seq.full
+ run_check $FIO_PROG $tmp-$seq.fio >> $seq.full
+}
+
+# real QA test starts here
+_supported_fs generic
+_supported_os Linux
+_supported_fs ext4
+_need_to_be_root
+_require_scratch
+
+_scratch_mkfs >> $seq.full 2>&1
+_scratch_mount
+
+if ! _workout; then
+ umount $SCRATCH_DEV 2>/dev/null
+ exit
+fi
+
+if ! _scratch_unmount; then
+ echo "failed to umount"
+ status=1
+ exit
+fi
+_check_scratch_fs
+status=$?
+exit
diff --git a/288.out b/288.out
new file mode 100644
index 0000000..b215a3f
--- /dev/null
+++ b/288.out
@@ -0,0 +1,4 @@
+QA output created by 288
+
+ Start defragment activity
+
diff --git a/group b/group
index 37f3256..8bd5c21 100644
--- a/group
+++ b/group
@@ -406,3 +406,4 @@ deprecated
285 auto dump quota quick
286 auto rw enospc aio
287 auto rw enospc aio prealloc
+288 auto rw aio
--
1.7.7.6
Run DIO, fallocate and truncate threads on a common file in parallel.
If race exist old dio request may rewrite blocks after it was allocated
to another file, we will catch that by verifying blocks content.
this patch known to catch deadlock for ext4
http://lists.openwall.net/linux-ext4/2012/09/06/3
Signed-off-by: Dmitry Monakhov <[email protected]>
---
286 | 153 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
286.out | 5 ++
group | 1 +
3 files changed, 159 insertions(+), 0 deletions(-)
create mode 100755 286
create mode 100644 286.out
diff --git a/286 b/286
new file mode 100755
index 0000000..beb9546
--- /dev/null
+++ b/286
@@ -0,0 +1,153 @@
+#! /bin/bash
+# FSQA Test No. 286
+#
+# Test various aio dio vs truncate
+#
+#-----------------------------------------------------------------------
+# Copyright (c) 2006 Silicon Graphics, Inc. All Rights Reserved.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation.
+#
+# This program is distributed in the hope that it would be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write the Free Software Foundation,
+# Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+#
+#-----------------------------------------------------------------------
+#
+# creator
[email protected]
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1 # failure is the default!
+trap "rm -f $tmp.*; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+run_check()
+{
+ echo "# $@" >> $seq.full 2>&1
+ "$@" >> $seq.full 2>&1 || _fail "failed: '$@'"
+}
+
+
+NUM_JOBS=$((4*LOAD_FACTOR))
+BLK_DEV_SIZE=`blockdev --getsz $SCRATCH_DEV`
+FILE_SIZE=$((BLK_DEV_SIZE * 512))
+
+cat >$tmp-$seq.fio <<EOF
+###########
+# $seq test fio activity
+[global]
+ioengine=libaio
+bs=128k
+directory=${SCRATCH_MNT}
+filesize=${FILE_SIZE}
+size=999G
+iodepth=128*${LOAD_FACTOR}
+continue_on_error=write
+ignore_error=,ENOSPC
+error_dump=0
+create_on_open=1
+fallocate=none
+exitall=1
+
+## Perform direct aio, to files which may be truncated
+## by external task
+[direct_aio]
+direct=1
+buffered=0
+numjobs=${NUM_JOBS}
+rw=randwrite
+runtime=100*${TIME_FACTOR}
+time_based
+
+# Perform direct aio and verify data
+[aio-dio-verifier]
+numjobs=1
+verify=crc32c-intel
+verify_fatal=1
+verify_dump=1
+verify_backlog=1024
+verify_async=4
+verifysort=1
+direct=1
+bs=4k
+rw=randrw
+filename=aio-dio-verifier
+
+# Perform buffered aio and verify data
+[buffered-aio-verifier]
+numjobs=1
+verify=crc32c-intel
+verify_fatal=1
+verify_dump=1
+verify_backlog=1024
+verify_async=4
+verifysort=1
+direct=0
+buffered=1
+bs=4k
+rw=randrw
+filename=buffered-aio-verifier
+EOF
+
+_workout()
+{
+ echo ""
+ echo "Run fio with random aio-dio pattern"
+ echo ""
+ cat $tmp-$seq.fio >> $seq.full
+ run_check $FIO_PROG $tmp-$seq.fio >> $seq.full &
+ pid=$!
+ echo "Start fallocate/truncate loop"
+ for ((i=0; ; i++))
+ do
+ for ((k=1; k <= NUM_JOBS; k++))
+ do
+ fallocate -l $FILE_SIZE $SCRATCH_MNT/direct_aio.$k.0 \
+ >> $seq.full 2>&1
+ done
+ for ((k=1; k <= NUM_JOBS; k++))
+ do
+ truncate -s 0 $SCRATCH_MNT/direct_aio.$k.0
+ done
+ # One fio exit we can stop fallocate/truncate loop
+ kill -0 $pid > /dev/null 2>&1 || break
+ done
+ wait $pid
+}
+
+# real QA test starts here
+_supported_fs generic
+_supported_os Linux
+_need_to_be_root
+_require_scratch
+
+_scratch_mkfs >> $seq.full 2>&1
+_scratch_mount
+
+if ! _workout; then
+ umount $SCRATCH_DEV 2>/dev/null
+ exit
+fi
+
+if ! _scratch_unmount; then
+ echo "failed to umount"
+ status=1
+ exit
+fi
+_check_scratch_fs
+status=$?
+exit
diff --git a/286.out b/286.out
new file mode 100644
index 0000000..d721996
--- /dev/null
+++ b/286.out
@@ -0,0 +1,5 @@
+QA output created by 286
+
+Run fio with random aio-dio pattern
+
+Start fallocate/truncate loop
diff --git a/group b/group
index 697269b..2469f80 100644
--- a/group
+++ b/group
@@ -404,3 +404,4 @@ deprecated
283 dump ioctl auto quick
284 auto
285 auto dump quota quick
+286 auto rw enospc aio
--
1.7.7.6
Signed-off-by: Dmitry Monakhov <[email protected]>
---
017 | 5 ++++-
068 | 4 ++--
070 | 4 +++-
076 | 5 ++++-
083 | 4 ++--
087 | 10 ++++++----
104 | 4 ++--
114 | 5 +++--
167 | 4 ++--
232 | 5 +++--
233 | 5 +++--
269 | 7 ++++---
270 | 7 ++++---
276 | 11 ++++++-----
14 files changed, 48 insertions(+), 32 deletions(-)
diff --git a/017 b/017
index 9ca0e72..8d35ee8 100755
--- a/017
+++ b/017
@@ -67,7 +67,10 @@ echo "*** test"
for l in 0 1 2 3 4
do
echo " *** test $l"
- $FSSTRESS_PROG -d $SCRATCH_MNT -n 1000 $FSSTRESS_AVOID >>$seq.full
+ NUM=$((1000 * TIME_FACTOR))
+ CPU=$((1 * LOAD_FACTOR))
+ $FSSTRESS_PROG -d $SCRATCH_MNT -n $NUM -p $CPU \
+ $FSSTRESS_AVOID >>$seq.full
_scratch_mount -o remount,ro \
|| _fail "remount ro failed"
diff --git a/068 b/068
index b595d1d..9a01100 100755
--- a/068
+++ b/068
@@ -75,8 +75,8 @@ touch $tmp.running
STRESS_DIR="$SCRATCH_MNT/fsstress_test_dir"
mkdir "$STRESS_DIR"
- procs=2
- nops=200
+ procs=$((2 * LOAD_FACTOR))
+ nops=$((200 * TIME_FACTOR))
while [ -f "$tmp.running" ]
do
# We do both read & write IO - not only is this more realistic,
diff --git a/070 b/070
index f48c33c..286ae90 100755
--- a/070
+++ b/070
@@ -62,7 +62,9 @@ $FSSTRESS_PROG \
-f unresvsp=0 \
-f attr_set=100 \
-f attr_remove=100 \
- -p 1 -n 10000 -S c >$seq.full 2>&1
+ -p $((LOAD_FACTOR)) \
+ -n $((10000 * TIME_FACTOR)) \
+ -S c >$seq.full 2>&1
status=$?
exit
diff --git a/076 b/076
index e472b26..fa1a916 100755
--- a/076
+++ b/076
@@ -74,7 +74,10 @@ echo "*** test concurrent block/fs access"
cat $SCRATCH_DEV >/dev/null &
pid=$!
-$FSSTRESS_PROG -d $SCRATCH_MNT -p 2 -n 2000 $FSSTRESS_AVOID >>$seq.full
+num=$((2000 * TIME_FACTOR))
+proc=$((2 * LOAD_FACTOR))
+
+$FSSTRESS_PROG -d $SCRATCH_MNT -p $proc -n $num $FSSTRESS_AVOID >>$seq.full
_lets_get_pidst
_check_scratch_fs
diff --git a/083 b/083
index e0670b9..7af7c08 100755
--- a/083
+++ b/083
@@ -66,8 +66,8 @@ workout()
{
fsz=$1
ags=$2
- procs=$3
- nops=$4
+ procs=$(($3 * LOAD_FACTOR))
+ nops=$(($4 * TIME_FACTOR))
umount $SCRATCH_DEV >/dev/null 2>&1
echo "*** mkfs -dsize=$fsz,agcount=$ags" >>$seq.full
diff --git a/087 b/087
index 48e5eaa..5c67f5e 100755
--- a/087
+++ b/087
@@ -43,11 +43,13 @@ trap "rm -f $tmp.*; exit \$status" 0 1 2 3 15
_do_meta()
{
out=$SCRATCH_MNT/fsstress
- count=10000
- param="-p 4 -z -f rmdir=10 -f link=10 -f creat=10 -f mkdir=10 \
+ count=$((10000 * TIME_FACTOR))
+ proc=$((4 * LOAD_FACTOR))
+ param="-z -f rmdir=10 -f link=10 -f creat=10 -f mkdir=10 \
-f rename=30 -f stat=30 -f unlink=30 -f truncate=20"
- _echofull "calling fsstress $param -m8 -n $count"
- if ! $FSSTRESS_PROG $param $FSSTRESS_AVOID -m 8 -n $count -d $out >>$seq.full 2>&1
+ _echofull "calling fsstress $param -m8 -p $proc -n $count"
+ if ! $FSSTRESS_PROG $param $FSSTRESS_AVOID -m 8 -p $proc \
+ -n $count -d $out >>$seq.full 2>&1
then
_echofull "fsstress failed"
fi
diff --git a/104 b/104
index 14f2669..abc9705 100755
--- a/104
+++ b/104
@@ -61,8 +61,8 @@ _fill_scratch()
_stress_scratch()
{
- procs=3
- nops=1000
+ procs=$((3 * LOAD_FACTOR))
+ nops=$((1000 * TIME_FACTOR))
# -w ensures that the only ops are ones which cause write I/O
$FSSTRESS_PROG -d $SCRATCH_MNT -w -p $procs -n $nops $FSSTRESS_AVOID > /dev/null &
}
diff --git a/114 b/114
index 7679222..348f992 100755
--- a/114
+++ b/114
@@ -245,12 +245,13 @@ _test_fsstress()
echo ""
out=$SCRATCH_MNT/fsstress.$$
- count=1000
+ count=$((1000 * TIME_FACTOR))
+ proc=$((3 * LOAD_FACTOR))
args="-z \
-f rmdir=10 -f link=10 -f creat=10 \
-f mkdir=10 -f rename=30 -f unlink=10 \
-f symlink=10 \
--n $count -d $out -p 3"
+-n $count -d $out -p $proc"
echo "fsstress $args" | sed -e "s#$out#outdir#"
if ! $FSSTRESS_PROG $args | _filter_num
diff --git a/167 b/167
index ccb6c2a..ad5fcd0 100755
--- a/167
+++ b/167
@@ -42,8 +42,8 @@ _cleanup()
workout()
{
- procs=100
- nops=15000
+ procs=$((100 * LOAD_FACTOR))
+ nops=$((15000 * TIME_FACTOR))
$FSSTRESS_PROG -d $SCRATCH_MNT -p $procs -n $nops $FSSTRESS_AVOID \
>>$seq.full &
sleep 2
diff --git a/232 b/232
index 2795da7..6cd0171 100755
--- a/232
+++ b/232
@@ -53,8 +53,9 @@ _fsstress()
echo ""
out=$SCRATCH_MNT/fsstress.$$
- count=2000
- args="-n $count -d $out -p 7"
+ count=$((2000*TIME_FACTOR))
+ CPU=$((7 * LOAD_FACTOR))
+ args="-n $count -d $out -p $CPU"
echo "fsstress $args" | tee -a $here/$seq.full | sed -e "s#$out#outdir#"
if ! $FSSTRESS_PROG $args | tee -a $here/$seq.full | _filter_num
diff --git a/233 b/233
index 28e6ac7..e30d9cc 100755
--- a/233
+++ b/233
@@ -57,11 +57,12 @@ _fsstress()
echo ""
out=$SCRATCH_MNT/fsstress.$$
- count=5000
+ count=$((5000 * TIME_FACTOR))
+ proc=$((7 * LOAD_FACTOR))
args="-z \
-f rmdir=20 -f link=10 -f creat=10 -f mkdir=10 -f unlink=20 -f symlink=10 \
-f rename=10 -f fsync=2 -f write=15 -f dwrite=15 \
--n $count -d $out -p 7"
+-n $count -d $out -p $proc"
echo "fsstress $args" | tee -a $here/$seq.full | sed -e "s#$out#outdir#"
if ! su $qa_user -c "$FSSTRESS_PROG $args" | tee -a $here/$seq.full | _filter_num
diff --git a/269 b/269
index 7e13ed9..ca2700c 100755
--- a/269
+++ b/269
@@ -42,10 +42,11 @@ _workout()
echo ""
echo "Run fsstress"
echo ""
- num_iterations=10
- enospc_time=2
+ num_iterations=$((10 * TIME_FACTOR))
+ enospc_time=$((2 * TIME_FACTOR))
+ proc=$((128 * LOAD_FACTOR))
out=$SCRATCH_MNT/fsstress.$$
- args="-p128 -n999999999 -f setattr=1 $FSSTRESS_AVOID -d $out"
+ args="-p $proc -n999999999 -f setattr=1 $FSSTRESS_AVOID -d $out"
echo "fsstress $args" >> $here/$seq.full
$FSSTRESS_PROG $args > /dev/null 2>&1 &
pid=$!
diff --git a/270 b/270
index b9ada27..5197910 100755
--- a/270
+++ b/270
@@ -45,10 +45,11 @@ _workout()
echo ""
echo "Run fsstress"
echo ""
- num_iterations=10
- enospc_time=2
+ num_iterations=$((10 * TIME_FACTOR))
+ enospc_time=$((2 * TIME_FACTOR))
+ proc=$((128 * LOAD_FACTOR))
out=$SCRATCH_MNT/fsstress.$$
- args="-p128 -n999999999 -f setattr=1 $FSSTRESS_AVOID -d $out"
+ args="-p$proc -n999999999 -f setattr=1 $FSSTRESS_AVOID -d $out"
echo "fsstress $args" >> $here/$seq.full
# Grant chown capability
cp $FSSTRESS_PROG $tmp.fsstress.bin
diff --git a/276 b/276
index 082f943..551bef7 100755
--- a/276
+++ b/276
@@ -175,7 +175,8 @@ workout()
{
fsz=$1
nfiles=$2
- procs=$3
+ procs=$(($3 * LOAD_FACTOR))
+ num=$((1000* TIME_FACTOR))
snap_name=$4
umount $SCRATCH_DEV >/dev/null 2>&1
@@ -185,8 +186,8 @@ workout()
|| _fail "size=$fsz mkfs failed"
run_check _scratch_mount
# -w ensures that the only ops are ones which cause write I/O
- run_check $FSSTRESS_PROG -d $SCRATCH_MNT -w -p $procs -n 1000 \
- $FSSTRESS_AVOID
+ run_check $FSSTRESS_PROG -d $SCRATCH_MNT -w -p $procs -n $num \
+ $FSSTRESS_AVOID
run_check $BTRFS_UTIL_PROG subvol snap $SCRATCH_MNT \
$SCRATCH_MNT/$snap_name
@@ -196,13 +197,13 @@ workout()
# make some noise but ensure we're not touching existing data
# extents.
- run_check $FSSTRESS_PROG -d $SCRATCH_MNT -p $procs -n 2000 \
+ run_check $FSSTRESS_PROG -d $SCRATCH_MNT -p $procs -n $((num*2)) \
-z -f chown=3 -f link=1 -f mkdir=2 -f mknod=2 \
-f rename=2 -f setxattr=1 -f symlink=2
clean_dir="$SCRATCH_MNT/next"
mkdir $clean_dir
# now make more files to get a higher tree
- run_check $FSSTRESS_PROG -d $clean_dir -w -p $procs -n 2000 \
+ run_check $FSSTRESS_PROG -d $clean_dir -w -p $procs -n $((num*2)) \
$FSSTRESS_AVOID
run_check umount $SCRATCH_DEV >/dev/null 2>&1
run_check _scratch_mount "-o atime"
--
1.7.7.6
On 9/23/12 2:24 PM, Dmitry Monakhov wrote:
> FIO is very flexible io generator, i would call it IO swiss knife.
> Currently we have tonnes of hardcoded application which reproduces
> some predefined scenario. This approach has obvious dissadvantages
> 1) Lack of flexability: once written it is hard to modify it in future
> 2) Code base is large, many routines written again and again
>
> At the same time add new fio based tast is just add simle INI file.
> This greatly simplify code review. I do beleve that some day we will
> replace most of hardcoded io binaries with fio.
The submodule approach is interesting, but I wonder - we have quite a few
dependencies on other binaries already; what are the pros and cons of creating
this as a git submodule vs. simply expecting fio to be installed on the
system like any of the other dependencies we have today?
(I package fio for Fedora, is it not commonly available on other
distros?)
-Eric
> Signed-off-by: Dmitry Monakhov <[email protected]>
> ---
> .gitmodules | 3 +++
> common.config | 3 +++
> src/Makefile | 8 +++++---
> src/aio-dio-regress/Makefile | 4 ++--
> src/fio | 1 +
> 5 files changed, 14 insertions(+), 5 deletions(-)
> create mode 100644 .gitmodules
> create mode 160000 src/fio
>
> diff --git a/.gitmodules b/.gitmodules
> new file mode 100644
> index 0000000..f0481ea
> --- /dev/null
> +++ b/.gitmodules
> @@ -0,0 +1,3 @@
> +[submodule "src/fio"]
> + path = src/fio
> + url = git://git.kernel.dk/fio.git
> diff --git a/common.config b/common.config
> index 7bed1c5..25cddb4 100644
> --- a/common.config
> +++ b/common.config
> @@ -138,6 +138,9 @@ export DF_PROG="`set_prog_path df`"
> [ "$DF_PROG" = "" ] && _fatal "df not found"
> [ "$HOSTOS" = "Linux" ] && export DF_PROG="$DF_PROG -T"
>
> +export FIO_PROG="`set_prog_path $PWD/src/fio/fio`"
> +[ "$FIO_PROG" = "" ] && _fatal "fio not found"
> +
> export XFS_LOGPRINT_PROG="`set_prog_path xfs_logprint`"
> export XFS_REPAIR_PROG="`set_prog_path xfs_repair`"
> export XFS_CHECK_PROG="`set_prog_path xfs_check`"
> diff --git a/src/Makefile b/src/Makefile
> index 67250ee..255bdd4 100644
> --- a/src/Makefile
> +++ b/src/Makefile
> @@ -52,16 +52,18 @@ LLDLIBS += $(LIBGDBM)
> endif
>
> ifeq ($(HAVE_AIO), true)
> -SUBDIRS += aio-dio-regress
> +SUBDIRS += aio-dio-regress \
> + fio
> +
> endif
>
> CFILES = $(TARGETS:=.c)
> LDIRT = $(TARGETS)
>
>
> -default: depend $(TARGETS) $(SUBDIRS)
> +default: .depend $(TARGETS) $(SUBDIRS)
>
> -depend: .dep
> +.depend: .dep
>
> include $(BUILDRULES)
>
> diff --git a/src/aio-dio-regress/Makefile b/src/aio-dio-regress/Makefile
> index 79dd55d..fcead9a 100644
> --- a/src/aio-dio-regress/Makefile
> +++ b/src/aio-dio-regress/Makefile
> @@ -8,9 +8,9 @@ LDIRT = $(TARGETS)
>
> LLDLIBS = -laio -lpthread
>
> -default: depend $(TARGETS)
> +default: .depend $(TARGETS)
>
> -depend: .dep
> +.depend: .dep
>
> include $(BUILDRULES)
>
> diff --git a/src/fio b/src/fio
> new file mode 160000
> index 0000000..e12d280
> --- /dev/null
> +++ b/src/fio
> @@ -0,0 +1 @@
> +Subproject commit e12d2800f811cb64d376cfdaed9a1257f3fa9c99
>
On Sun, 23 Sep 2012 22:16:57 -0500, Eric Sandeen <[email protected]> wrote:
> On 9/23/12 2:24 PM, Dmitry Monakhov wrote:
> > FIO is very flexible io generator, i would call it IO swiss knife.
> > Currently we have tonnes of hardcoded application which reproduces
> > some predefined scenario. This approach has obvious dissadvantages
> > 1) Lack of flexability: once written it is hard to modify it in future
> > 2) Code base is large, many routines written again and again
> >
> > At the same time add new fio based tast is just add simle INI file.
> > This greatly simplify code review. I do beleve that some day we will
> > replace most of hardcoded io binaries with fio.
>
> The submodule approach is interesting, but I wonder - we have quite a few
> dependencies on other binaries already; what are the pros and cons of creating
> this as a git submodule vs. simply expecting fio to be installed on the
> system like any of the other dependencies we have today?
Pro:
P1) allow to specify exact commit as a submodule HEAD this guarantee
that we will have known version and functionality regardless to
distribution package manager (which are known to be very conservative)
P2) Prevent duplicating of source code (fsstress.c/aio-stress.c and
etc). If some one want to add new feature to submodule he
simply push it to official submodule repo and move submodule HEAD
In that both parties(submodule maintainer and project maintainer)
will benefit because new features will be available to every
submodule user
Cons:
C1) New dependencies
C2) Learn people how to work with submodules
I'll not assume (C2) as a serious argument because this is just one more
git's command. For most users should just add new option to clone:
git clone --recursive git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
(C1) Is not big deal in case of Fio because we already depends from
libaio.
(P2) Makes xfstest coverage larger because all new tests which use new
submodules functionality will start to work by default (today it
silently ignored). As i already told fio is under rapid
development Jens Axboe does very good job so (P2) really works for
me, new features i need for xfstets was reviewed and accepted by Jens
http://git.kernel.dk/?p=fio.git;a=commit;h=8b28bd41375930664a0ff9ff9b101a88ac416ac5
http://git.kernel.dk/?p=fio.git;a=commit;h=9c25d2e3f498707c4fd5a4bb0adf9867ecb17768
http://git.kernel.dk/?p=fio.git;a=commit;h=e615ceafbe3962a35b7a7e06a0c8f4e2c0652c65
>
> (I package fio for Fedora, is it not commonly available on other
> distros?)
>
> -Eric
>
> > Signed-off-by: Dmitry Monakhov <[email protected]>
> > ---
> > .gitmodules | 3 +++
> > common.config | 3 +++
> > src/Makefile | 8 +++++---
> > src/aio-dio-regress/Makefile | 4 ++--
> > src/fio | 1 +
> > 5 files changed, 14 insertions(+), 5 deletions(-)
> > create mode 100644 .gitmodules
> > create mode 160000 src/fio
> >
> > diff --git a/.gitmodules b/.gitmodules
> > new file mode 100644
> > index 0000000..f0481ea
> > --- /dev/null
> > +++ b/.gitmodules
> > @@ -0,0 +1,3 @@
> > +[submodule "src/fio"]
> > + path = src/fio
> > + url = git://git.kernel.dk/fio.git
> > diff --git a/common.config b/common.config
> > index 7bed1c5..25cddb4 100644
> > --- a/common.config
> > +++ b/common.config
> > @@ -138,6 +138,9 @@ export DF_PROG="`set_prog_path df`"
> > [ "$DF_PROG" = "" ] && _fatal "df not found"
> > [ "$HOSTOS" = "Linux" ] && export DF_PROG="$DF_PROG -T"
> >
> > +export FIO_PROG="`set_prog_path $PWD/src/fio/fio`"
> > +[ "$FIO_PROG" = "" ] && _fatal "fio not found"
> > +
> > export XFS_LOGPRINT_PROG="`set_prog_path xfs_logprint`"
> > export XFS_REPAIR_PROG="`set_prog_path xfs_repair`"
> > export XFS_CHECK_PROG="`set_prog_path xfs_check`"
> > diff --git a/src/Makefile b/src/Makefile
> > index 67250ee..255bdd4 100644
> > --- a/src/Makefile
> > +++ b/src/Makefile
> > @@ -52,16 +52,18 @@ LLDLIBS += $(LIBGDBM)
> > endif
> >
> > ifeq ($(HAVE_AIO), true)
> > -SUBDIRS += aio-dio-regress
> > +SUBDIRS += aio-dio-regress \
> > + fio
> > +
> > endif
> >
> > CFILES = $(TARGETS:=.c)
> > LDIRT = $(TARGETS)
> >
> >
> > -default: depend $(TARGETS) $(SUBDIRS)
> > +default: .depend $(TARGETS) $(SUBDIRS)
> >
> > -depend: .dep
> > +.depend: .dep
> >
> > include $(BUILDRULES)
> >
> > diff --git a/src/aio-dio-regress/Makefile b/src/aio-dio-regress/Makefile
> > index 79dd55d..fcead9a 100644
> > --- a/src/aio-dio-regress/Makefile
> > +++ b/src/aio-dio-regress/Makefile
> > @@ -8,9 +8,9 @@ LDIRT = $(TARGETS)
> >
> > LLDLIBS = -laio -lpthread
> >
> > -default: depend $(TARGETS)
> > +default: .depend $(TARGETS)
> >
> > -depend: .dep
> > +.depend: .dep
> >
> > include $(BUILDRULES)
> >
> > diff --git a/src/fio b/src/fio
> > new file mode 160000
> > index 0000000..e12d280
> > --- /dev/null
> > +++ b/src/fio
> > @@ -0,0 +1 @@
> > +Subproject commit e12d2800f811cb64d376cfdaed9a1257f3fa9c99
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Sep 24, 2012 at 02:03:42PM +0400, Dmitry Monakhov wrote:
> On Sun, 23 Sep 2012 22:16:57 -0500, Eric Sandeen <[email protected]> wrote:
> > On 9/23/12 2:24 PM, Dmitry Monakhov wrote:
> > > FIO is very flexible io generator, i would call it IO swiss knife.
> > > Currently we have tonnes of hardcoded application which reproduces
> > > some predefined scenario. This approach has obvious dissadvantages
> > > 1) Lack of flexability: once written it is hard to modify it in future
> > > 2) Code base is large, many routines written again and again
> > >
> > > At the same time add new fio based tast is just add simle INI file.
> > > This greatly simplify code review. I do beleve that some day we will
> > > replace most of hardcoded io binaries with fio.
> >
> > The submodule approach is interesting, but I wonder - we have quite a few
> > dependencies on other binaries already; what are the pros and cons of creating
> > this as a git submodule vs. simply expecting fio to be installed on the
> > system like any of the other dependencies we have today?
> Pro:
> P1) allow to specify exact commit as a submodule HEAD this guarantee
> that we will have known version and functionality regardless to
> distribution package manager (which are known to be very conservative)
You haven't provided a method to do this in this patch. All
you've provided is a submodule that tracks the fio tree head.
All this needs to be properly documented in the README file, at
minimum.
And conservative is good, too. I don't want tests to fail because of
rapid changes in the fio tree causing regressions in fio itself. The
tools that xfstests depends on need to be stable and relatively
unchanging, because we're not testing them - we're testing the
filesystem. The less the environemnt changes around the things we're
actually supposed to be regression testing, the better.
> P2) Prevent duplicating of source code (fsstress.c/aio-stress.c and
> etc). If some one want to add new feature to submodule he
> simply push it to official submodule repo and move submodule HEAD
> In that both parties(submodule maintainer and project maintainer)
> will benefit because new features will be available to every
> submodule user
> Cons:
> C1) New dependencies
> C2) Learn people how to work with submodules
>
> I'll not assume (C2) as a serious argument because this is just one more
> git's command. For most users should just add new option to clone:
> git clone --recursive git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
Doesn't work for me. I keep local mirrors of all git trees that I
use regularly and update them by cron jobs so that I don't have to
go to the internet for every local tree that I clone or update.
That's particularly important for me because I'm a *long* way from
the US or Europe and cloning from scratch over the internet takes a
long time and suck up a lot of bandwidth. I don't even allow my test
machines to access the internet - they only know about the local
network and mirrors. I'd have to overide the fio submodule URL in
the xfstests repository on every test machine, and that gets messy
in a hurry.
Also, we distribute xfstests as a tarball, and there has been talk of
proper packaging (rpm/deb) as well. In those cases, the git
submodule approach does not work as we have to depend on the distro
supplied fio packages...
> (C1) Is not big deal in case of Fio because we already depends from
> libaio.
There's also a fio version dependency. i.e. _require_fio has to
detect whether the currently installed fio is of sufficiently recent
version for the tests to run.
> (P2) Makes xfstest coverage larger because all new tests which use new
> submodules functionality will start to work by default (today it
> silently ignored). As i already told fio is under rapid
> development Jens Axboe does very good job so (P2) really works for
> me, new features i need for xfstets was reviewed and accepted by Jens
> http://git.kernel.dk/?p=fio.git;a=commit;h=8b28bd41375930664a0ff9ff9b101a88ac416ac5
> http://git.kernel.dk/?p=fio.git;a=commit;h=9c25d2e3f498707c4fd5a4bb0adf9867ecb17768
> http://git.kernel.dk/?p=fio.git;a=commit;h=e615ceafbe3962a35b7a7e06a0c8f4e2c0652c65
For me, that's not a "pro" - that's a "con" as i explained above.
> > (I package fio for Fedora, is it not commonly available on other
> > distros?)
Available for Debian, which means all it's derivatives also have it.
In short, I'd prefer we continue to use package level dependencies
detected through configure/_require_foo infrastructure than using
source tree level dependencies. Package level dependencies are much,
much easier to manage for most people and don't require everyone to
have internet access on the machines that xfstests is being built
on....
Cheers,
Dave.
--
Dave Chinner
[email protected]
On Sun, Sep 23, 2012 at 11:16 PM, Eric Sandeen <[email protected]> wrote:
> (I package fio for Fedora, is it not commonly available on other
> distros?)
opensuse has it in the benchmarking repo, but not in the main release
repos. If it is getting regular updates and users will want to have
the latest version, it makes sense for opensuse to leave it that way.
This discussion may change that.
As of a year ago, xfstests dependencies could all be met from the main
repos. (see howto http://en.opensuse.org/SDB:XFStests)
I believe a basic set of xfstests is run as part of the QA process for
every factory build (factory is similar to rawhide). At least it was
during 12.1 pre-release testing a year ago.
http://openqa.opensuse.org/results/
Not a huge deal, but having xfstests tests which depend on fio would
either mean opensuse dropping those tests that depend on fio from its
routine QA testing, or it would mean adding fio to the main distro.
How far into xfstests is fio likely to integrate? If it is to become
a core tool and it is not going to be provided by xfstests itself, I
can try to submit fio to factory. It will just have to kept new
enough to satisfy xfstests version requirements.
I do hope that if the distro has to provide a fio package, then
xfstests only depend on the version, not the git check-in.
Greg
On Mon, 24 Sep 2012 21:37:18 +1000, Dave Chinner <[email protected]> wrote:
> On Mon, Sep 24, 2012 at 02:03:42PM +0400, Dmitry Monakhov wrote:
> > On Sun, 23 Sep 2012 22:16:57 -0500, Eric Sandeen <[email protected]> wrote:
> > > On 9/23/12 2:24 PM, Dmitry Monakhov wrote:
> > > > FIO is very flexible io generator, i would call it IO swiss knife.
> > > > Currently we have tonnes of hardcoded application which reproduces
> > > > some predefined scenario. This approach has obvious dissadvantages
> > > > 1) Lack of flexability: once written it is hard to modify it in future
> > > > 2) Code base is large, many routines written again and again
> > > >
> > > > At the same time add new fio based tast is just add simle INI file.
> > > > This greatly simplify code review. I do beleve that some day we will
> > > > replace most of hardcoded io binaries with fio.
> > >
> > > The submodule approach is interesting, but I wonder - we have quite a few
> > > dependencies on other binaries already; what are the pros and cons of creating
> > > this as a git submodule vs. simply expecting fio to be installed on the
> > > system like any of the other dependencies we have today?
> > Pro:
> > P1) allow to specify exact commit as a submodule HEAD this guarantee
> > that we will have known version and functionality regardless to
> > distribution package manager (which are known to be very conservative)
>
> You haven't provided a method to do this in this patch. All
> you've provided is a submodule that tracks the fio tree head.
> All this needs to be properly documented in the README file, at
> minimum.
>
> And conservative is good, too. I don't want tests to fail because of
> rapid changes in the fio tree causing regressions in fio itself. The
> tools that xfstests depends on need to be stable and relatively
> unchanging, because we're not testing them - we're testing the
> filesystem. The less the environemnt changes around the things we're
> actually supposed to be regression testing, the better.
Yes, but we do not have to advance submodule update unless we need it.
Project may goes forward but we still can use old commit if needed.
>
> > P2) Prevent duplicating of source code (fsstress.c/aio-stress.c and
> > etc). If some one want to add new feature to submodule he
> > simply push it to official submodule repo and move submodule HEAD
> > In that both parties(submodule maintainer and project maintainer)
> > will benefit because new features will be available to every
> > submodule user
> > Cons:
> > C1) New dependencies
> > C2) Learn people how to work with submodules
> >
> > I'll not assume (C2) as a serious argument because this is just one more
> > git's command. For most users should just add new option to clone:
> > git clone --recursive git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
>
> Doesn't work for me. I keep local mirrors of all git trees that I
> use regularly and update them by cron jobs so that I don't have to
> go to the internet for every local tree that I clone or update.
>
> That's particularly important for me because I'm a *long* way from
> the US or Europe and cloning from scratch over the internet takes a
> long time and suck up a lot of bandwidth. I don't even allow my test
> machines to access the internet - they only know about the local
> network and mirrors. I'd have to overide the fio submodule URL in
> the xfstests repository on every test machine, and that gets messy
> in a hurry.
>
> Also, we distribute xfstests as a tarball, and there has been talk of
> proper packaging (rpm/deb) as well. In those cases, the git
> submodule approach does not work as we have to depend on the distro
> supplied fio packages...
Yes, if this is mandatory. it makes packaging harder but not too
complex.
>
> > (C1) Is not big deal in case of Fio because we already depends from
> > libaio.
>
> There's also a fio version dependency. i.e. _require_fio has to
> detect whether the currently installed fio is of sufficiently recent
> version for the tests to run.
>
> > (P2) Makes xfstest coverage larger because all new tests which use new
> > submodules functionality will start to work by default (today it
> > silently ignored). As i already told fio is under rapid
> > development Jens Axboe does very good job so (P2) really works for
> > me, new features i need for xfstets was reviewed and accepted by Jens
> > http://git.kernel.dk/?p=fio.git;a=commit;h=8b28bd41375930664a0ff9ff9b101a88ac416ac5
> > http://git.kernel.dk/?p=fio.git;a=commit;h=9c25d2e3f498707c4fd5a4bb0adf9867ecb17768
> > http://git.kernel.dk/?p=fio.git;a=commit;h=e615ceafbe3962a35b7a7e06a0c8f4e2c0652c65
>
> For me, that's not a "pro" - that's a "con" as i explained above.
>
> > > (I package fio for Fedora, is it not commonly available on other
> > > distros?)
>
> Available for Debian, which means all it's derivatives also have it.
>
> In short, I'd prefer we continue to use package level dependencies
> detected through configure/_require_foo infrastructure than using
> source tree level dependencies. Package level dependencies are much,
> much easier to manage for most people and don't require everyone to
> have internet access on the machines that xfstests is being built
> on....
Ok i'll go back to _require_fio $VER approach, but it is reasonable to
add prep script which will fetch or install all necessary packages
so user can explicitly run it if internet is available.
>
> Cheers,
>
> Dave.
> --
> Dave Chinner
> [email protected]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, 24 Sep 2012 08:23:04 -0400, Greg Freemyer <[email protected]> wrote:
> On Sun, Sep 23, 2012 at 11:16 PM, Eric Sandeen <[email protected]> wrote:
> > (I package fio for Fedora, is it not commonly available on other
> > distros?)
>
> opensuse has it in the benchmarking repo, but not in the main release
> repos. If it is getting regular updates and users will want to have
> the latest version, it makes sense for opensuse to leave it that way.
> This discussion may change that.
>
> As of a year ago, xfstests dependencies could all be met from the main
> repos. (see howto http://en.opensuse.org/SDB:XFStests)
>
> I believe a basic set of xfstests is run as part of the QA process for
> every factory build (factory is similar to rawhide). At least it was
> during 12.1 pre-release testing a year ago.
> http://openqa.opensuse.org/results/
>
> Not a huge deal, but having xfstests tests which depend on fio would
> either mean opensuse dropping those tests that depend on fio from its
> routine QA testing, or it would mean adding fio to the main distro.
>
> How far into xfstests is fio likely to integrate? If it is to become
> a core tool and it is not going to be provided by xfstests itself, I
> can try to submit fio to factory. It will just have to kept new
> enough to satisfy xfstests version requirements.
As far as i can say fio potentially can replace most of hardcoded
regression binaries.
>
> I do hope that if the distro has to provide a fio package, then
> xfstests only depend on the version, not the git check-in.
>
> Greg
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Sep 24, 2012 at 04:38:00PM +0400, Dmitry Monakhov wrote:
> On Mon, 24 Sep 2012 21:37:18 +1000, Dave Chinner <[email protected]> wrote:
> > On Mon, Sep 24, 2012 at 02:03:42PM +0400, Dmitry Monakhov wrote:
> > > On Sun, 23 Sep 2012 22:16:57 -0500, Eric Sandeen <[email protected]> wrote:
> > > > On 9/23/12 2:24 PM, Dmitry Monakhov wrote:
> > > > > FIO is very flexible io generator, i would call it IO swiss knife.
> > > > > Currently we have tonnes of hardcoded application which reproduces
> > > > > some predefined scenario. This approach has obvious dissadvantages
> > > > > 1) Lack of flexability: once written it is hard to modify it in future
> > > > > 2) Code base is large, many routines written again and again
> > > > >
> > > > > At the same time add new fio based tast is just add simle INI file.
> > > > > This greatly simplify code review. I do beleve that some day we will
> > > > > replace most of hardcoded io binaries with fio.
> > > >
> > > > The submodule approach is interesting, but I wonder - we have quite a few
> > > > dependencies on other binaries already; what are the pros and cons of creating
> > > > this as a git submodule vs. simply expecting fio to be installed on the
> > > > system like any of the other dependencies we have today?
> > > Pro:
> > > P1) allow to specify exact commit as a submodule HEAD this guarantee
> > > that we will have known version and functionality regardless to
> > > distribution package manager (which are known to be very conservative)
> >
> > You haven't provided a method to do this in this patch. All
> > you've provided is a submodule that tracks the fio tree head.
> > All this needs to be properly documented in the README file, at
> > minimum.
> >
> > And conservative is good, too. I don't want tests to fail because of
> > rapid changes in the fio tree causing regressions in fio itself. The
> > tools that xfstests depends on need to be stable and relatively
> > unchanging, because we're not testing them - we're testing the
> > filesystem. The less the environemnt changes around the things we're
> > actually supposed to be regression testing, the better.
> Yes, but we do not have to advance submodule update unless we need it.
> Project may goes forward but we still can use old commit if needed.
Sure, but that them means we need to track fio closely enough and
commit changes to the upstream xfstests repository whenever someone
needs to move it forward. It's a centralised solution that doesn't
improve the workflow of significant users of xfstests.
Indeed, what happens if we take this and run it on an old distro or
platform that a current fio hasn't even been tested on (e.g. RHEL
5.x, SLES10.x, MIPSEL or SH)? i.e. what happens when the blessed
xfstests fio version doesn't even compile on the test target? It
gets messy in a hurry because the xfstests maintainers have to solve
that problem.
I *much* prefer to have external dependencies handled the same way
for all external tools and libraries: if the distro doesn't supply
it, then the user needs to download it, install it and get it
working themselves. If they don't install it or the installed
version is too old, then the tests get skipped. That moves the
burden of dealing with fio integration issues to the end user, not
onto the xfstests maintainers. End users are scalable, maintainers
are not.
> > > P2) Prevent duplicating of source code (fsstress.c/aio-stress.c and
> > > etc). If some one want to add new feature to submodule he
> > > simply push it to official submodule repo and move submodule HEAD
> > > In that both parties(submodule maintainer and project maintainer)
> > > will benefit because new features will be available to every
> > > submodule user
> > > Cons:
> > > C1) New dependencies
> > > C2) Learn people how to work with submodules
> > >
> > > I'll not assume (C2) as a serious argument because this is just one more
> > > git's command. For most users should just add new option to clone:
> > > git clone --recursive git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
> >
> > Doesn't work for me. I keep local mirrors of all git trees that I
> > use regularly and update them by cron jobs so that I don't have to
> > go to the internet for every local tree that I clone or update.
> >
> > That's particularly important for me because I'm a *long* way from
> > the US or Europe and cloning from scratch over the internet takes a
> > long time and suck up a lot of bandwidth. I don't even allow my test
> > machines to access the internet - they only know about the local
> > network and mirrors. I'd have to overide the fio submodule URL in
> > the xfstests repository on every test machine, and that gets messy
> > in a hurry.
> >
> > Also, we distribute xfstests as a tarball, and there has been talk of
> > proper packaging (rpm/deb) as well. In those cases, the git
> > submodule approach does not work as we have to depend on the distro
> > supplied fio packages...
> Yes, if this is mandatory. it makes packaging harder but not too
> complex.
IMO, the submodule approach is an all-or-nothing approach that is
difficult to opt-out of or work around. Making it harder to maintain
a working test environment for a significant percentage of the
xfstests userbase is not a win, IMO.
> > > (C1) Is not big deal in case of Fio because we already depends from
> > > libaio.
> >
> > There's also a fio version dependency. i.e. _require_fio has to
> > detect whether the currently installed fio is of sufficiently recent
> > version for the tests to run.
> >
> > > (P2) Makes xfstest coverage larger because all new tests which use new
> > > submodules functionality will start to work by default (today it
> > > silently ignored). As i already told fio is under rapid
> > > development Jens Axboe does very good job so (P2) really works for
> > > me, new features i need for xfstets was reviewed and accepted by Jens
> > > http://git.kernel.dk/?p=fio.git;a=commit;h=8b28bd41375930664a0ff9ff9b101a88ac416ac5
> > > http://git.kernel.dk/?p=fio.git;a=commit;h=9c25d2e3f498707c4fd5a4bb0adf9867ecb17768
> > > http://git.kernel.dk/?p=fio.git;a=commit;h=e615ceafbe3962a35b7a7e06a0c8f4e2c0652c65
> >
> > For me, that's not a "pro" - that's a "con" as i explained above.
> >
> > > > (I package fio for Fedora, is it not commonly available on other
> > > > distros?)
> >
> > Available for Debian, which means all it's derivatives also have it.
> >
> > In short, I'd prefer we continue to use package level dependencies
> > detected through configure/_require_foo infrastructure than using
> > source tree level dependencies. Package level dependencies are much,
> > much easier to manage for most people and don't require everyone to
> > have internet access on the machines that xfstests is being built
> > on....
> Ok i'll go back to _require_fio $VER approach, but it is reasonable to
> add prep script which will fetch or install all necessary packages
> so user can explicitly run it if internet is available.
I don't think that a "fetch and build this tool" script is really
something that is part of xfstests. Having the configure scripts
warn that the required version of fio was not found and giving a
pointer to the repository is consistent with the way we curently
handle missing external build dependencies. Yes, I dislike autoconf
at times, too, but I think it's a better solution to external
dependencies at the source level for xfstests than git
submodules.....
Cheers,
Dave.
--
Dave Chinner
[email protected]