[PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space

[PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space

[Eryu Guan]

Make sure inodes can be allocated in new space added by xfs_growfs.

Regression test for
xfs: allow inode allocations in post-growfs disk space

Cc: Eric Sandeen <esandeen@redhat.com>
Cc: Boris Ranto <branto@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
---
 common/rc         | 11 +++++++
 tests/xfs/015     | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/xfs/015.out |  2 ++
 tests/xfs/group   |  1 +
 4 files changed, 113 insertions(+)
 create mode 100755 tests/xfs/015
 create mode 100644 tests/xfs/015.out

diff --git a/common/rc b/common/rc
index 2c83340..255dd9b 100644
--- a/common/rc
+++ b/common/rc
@@ -2225,6 +2225,17 @@ _require_btrfs_fs_feature()
 		_notrun "Feature $feat not supported by the available btrfs version"
 }
 
+_get_free_inode()
+{
+	if [ -z "$1" ]; then
+		echo "Usage: _get_free_inode <mnt>"
+		exit 1
+	fi
+	local nr_inode;
+	nr_inode=`$DF_PROG -i $1 | tail -1 | awk '{print $5}'`
+	echo $nr_inode
+}
+
 init_rc()
 {
 	if [ "$iam" == new ]
diff --git a/tests/xfs/015 b/tests/xfs/015
new file mode 100755
index 0000000..3db2e0b
--- /dev/null
+++ b/tests/xfs/015
@@ -0,0 +1,99 @@
+#! /bin/bash
+# FS QA Test No. xfs/015
+#
+# Make sure inodes can be allocated in new space added by xfs_growfs
+#
+# Regression test for
+# xfs: allow inode allocations in post-growfs disk space
+#
+#-----------------------------------------------------------------------
+# Copyright (c) 2014 Red Hat 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
+#-----------------------------------------------------------------------
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1	# failure is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+    cd /
+    rm -f $tmp.*
+}
+
+create_file()
+{
+	local dir=$1
+	local i=0
+
+	while echo -n >$dir/testfile_$i; do
+		let i=$i+1
+	done
+}
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# real QA test starts here
+_supported_fs xfs
+_supported_os Linux
+
+_require_scratch
+
+rm -f $seqres.full
+echo "Silence is golden"
+
+_scratch_mkfs_sized $((128 * 1024 * 1024)) | _filter_mkfs >$seqres.full 2>$tmp.mkfs
+# get original data blocks number
+. $tmp.mkfs
+_scratch_mount
+
+# Create files to consume free inodes in background
+(
+	i=0
+	while [ $i -lt 1000 ]; do
+		mkdir $SCRATCH_MNT/testdir_$i
+		create_file $SCRATCH_MNT/testdir_$i &
+		let i=$i+1
+	done
+) >/dev/null 2>&1 &
+
+# Grow fs at the same time, at least x4
+# doubling or tripling the size couldn't reproduce
+$XFS_GROWFS_PROG -D $((dblocks * 4)) $SCRATCH_MNT >>$seqres.full
+
+# Wait for background create_file to hit ENOSPC
+wait
+
+# log inode status in $seqres.full for debug purpose
+echo "Inode status after growing fs" >>$seqres.full
+$DF_PROG -i $SCRATCH_MNT >>$seqres.full
+
+# Check free inode count, we expect all free inodes are taken
+free_inode=`_get_free_inode $SCRATCH_MNT`
+if [ $free_inode -gt 0 ]; then
+	echo "$free_inode free inodes available, newly added space not being used"
+else
+	status=0
+fi
+
+exit
diff --git a/tests/xfs/015.out b/tests/xfs/015.out
new file mode 100644
index 0000000..fee0fcf
--- /dev/null
+++ b/tests/xfs/015.out
@@ -0,0 +1,2 @@
+QA output created by 015
+Silence is golden
diff --git a/tests/xfs/group b/tests/xfs/group
index d5b50b7..0aab336 100644
--- a/tests/xfs/group
+++ b/tests/xfs/group
@@ -12,6 +12,7 @@
 012 rw auto quick
 013 auto metadata stress
 014 auto enospc quick quota
+015 auto enospc growfs
 016 rw auto quick
 017 mount auto quick stress
 018 deprecated # log logprint v2log
-- 
1.9.3

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space

[Brian Foster]

On Thu, Jul 17, 2014 at 12:52:33AM +0800, Eryu Guan wrote:
> Make sure inodes can be allocated in new space added by xfs_growfs.
> 
> Regression test for
> xfs: allow inode allocations in post-growfs disk space
> 
> Cc: Eric Sandeen <esandeen@redhat.com>
> Cc: Boris Ranto <branto@redhat.com>
> Signed-off-by: Eryu Guan <eguan@redhat.com>
> ---
>  common/rc         | 11 +++++++
>  tests/xfs/015     | 99 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
>  tests/xfs/015.out |  2 ++
>  tests/xfs/group   |  1 +
>  4 files changed, 113 insertions(+)
>  create mode 100755 tests/xfs/015
>  create mode 100644 tests/xfs/015.out
> 
> diff --git a/common/rc b/common/rc
> index 2c83340..255dd9b 100644
> --- a/common/rc
> +++ b/common/rc
> @@ -2225,6 +2225,17 @@ _require_btrfs_fs_feature()
>  		_notrun "Feature $feat not supported by the available btrfs version"
>  }
>  
> +_get_free_inode()
> +{
> +	if [ -z "$1" ]; then
> +		echo "Usage: _get_free_inode <mnt>"
> +		exit 1
> +	fi
> +	local nr_inode;
> +	nr_inode=`$DF_PROG -i $1 | tail -1 | awk '{print $5}'`
> +	echo $nr_inode
> +}
> +
>  init_rc()
>  {
>  	if [ "$iam" == new ]
> diff --git a/tests/xfs/015 b/tests/xfs/015
> new file mode 100755
> index 0000000..3db2e0b
> --- /dev/null
> +++ b/tests/xfs/015
> @@ -0,0 +1,99 @@
> +#! /bin/bash
> +# FS QA Test No. xfs/015
> +#
> +# Make sure inodes can be allocated in new space added by xfs_growfs
> +#
> +# Regression test for
> +# xfs: allow inode allocations in post-growfs disk space
> +#
> +#-----------------------------------------------------------------------
> +# Copyright (c) 2014 Red Hat 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
> +#-----------------------------------------------------------------------
> +#
> +
> +seq=`basename $0`
> +seqres=$RESULT_DIR/$seq
> +echo "QA output created by $seq"
> +
> +here=`pwd`
> +tmp=/tmp/$$
> +status=1	# failure is the default!
> +trap "_cleanup; exit \$status" 0 1 2 3 15
> +
> +_cleanup()
> +{
> +    cd /
> +    rm -f $tmp.*
> +}
> +
> +create_file()
> +{
> +	local dir=$1
> +	local i=0
> +
> +	while echo -n >$dir/testfile_$i; do
> +		let i=$i+1
> +	done
> +}
> +
> +# get standard environment, filters and checks
> +. ./common/rc
> +. ./common/filter
> +
> +# real QA test starts here
> +_supported_fs xfs
> +_supported_os Linux
> +
> +_require_scratch
> +
> +rm -f $seqres.full
> +echo "Silence is golden"
> +
> +_scratch_mkfs_sized $((128 * 1024 * 1024)) | _filter_mkfs >$seqres.full 2>$tmp.mkfs
> +# get original data blocks number
> +. $tmp.mkfs
> +_scratch_mount
> +

You could probably even make this smaller and make the test quicker.
E.g., I can create an fs down to 20M or so without any problems.  Also,
setting imaxpct=0 might be a good idea so you don't hit that artificial
limit.

> +# Create files to consume free inodes in background
> +(
> +	i=0
> +	while [ $i -lt 1000 ]; do
> +		mkdir $SCRATCH_MNT/testdir_$i
> +		create_file $SCRATCH_MNT/testdir_$i &
> +		let i=$i+1
> +	done
> +) >/dev/null 2>&1 &
> +
> +# Grow fs at the same time, at least x4
> +# doubling or tripling the size couldn't reproduce
> +$XFS_GROWFS_PROG -D $((dblocks * 4)) $SCRATCH_MNT >>$seqres.full
> +

Even though this is still relatively small based on what people probably
typically test, we're still making assumptions about the size of the
scratch device. It may be better to create the fs as a file on TEST_DEV.
Then you could do something like truncate to a fixed starting size, mkfs
at ~20MB and just growfs to the full size of the file. A 4x grow at that
point is then still only ~80MB, though hopefully it still doesn't run
too long on slower machines.

> +# Wait for background create_file to hit ENOSPC
> +wait
> +
> +# log inode status in $seqres.full for debug purpose
> +echo "Inode status after growing fs" >>$seqres.full
> +$DF_PROG -i $SCRATCH_MNT >>$seqres.full
> +
> +# Check free inode count, we expect all free inodes are taken
> +free_inode=`_get_free_inode $SCRATCH_MNT`
> +if [ $free_inode -gt 0 ]; then
> +	echo "$free_inode free inodes available, newly added space not being used"
> +else
> +	status=0
> +fi

This might not be the best metric either. I believe the free inodes
count that 'df -Ti' returns is a somewhat artificial calculation based
on the number of free blocks available, since we can do dynamic inode
allocation. It doesn't necessarily mean that all blocks can be allocated
to inodes however (e.g., due to alignment or extent length constraints),
so it might never actually read 0 unless the filesystem is perfectly
full.

Perhaps consider something like the IUse percentage over a certain
threshold?

Brian

> +
> +exit
> diff --git a/tests/xfs/015.out b/tests/xfs/015.out
> new file mode 100644
> index 0000000..fee0fcf
> --- /dev/null
> +++ b/tests/xfs/015.out
> @@ -0,0 +1,2 @@
> +QA output created by 015
> +Silence is golden
> diff --git a/tests/xfs/group b/tests/xfs/group
> index d5b50b7..0aab336 100644
> --- a/tests/xfs/group
> +++ b/tests/xfs/group
> @@ -12,6 +12,7 @@
>  012 rw auto quick
>  013 auto metadata stress
>  014 auto enospc quick quota
> +015 auto enospc growfs
>  016 rw auto quick
>  017 mount auto quick stress
>  018 deprecated # log logprint v2log
> -- 
> 1.9.3
> 
> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space

[Dave Chinner]

On Mon, Jul 21, 2014 at 09:46:38AM -0400, Brian Foster wrote:
> On Thu, Jul 17, 2014 at 12:52:33AM +0800, Eryu Guan wrote:
> > Make sure inodes can be allocated in new space added by xfs_growfs.
> > 
> > Regression test for
> > xfs: allow inode allocations in post-growfs disk space
....
> > +# Create files to consume free inodes in background
> > +(
> > +	i=0
> > +	while [ $i -lt 1000 ]; do
> > +		mkdir $SCRATCH_MNT/testdir_$i
> > +		create_file $SCRATCH_MNT/testdir_$i &
> > +		let i=$i+1
> > +	done
> > +) >/dev/null 2>&1 &
> > +
> > +# Grow fs at the same time, at least x4
> > +# doubling or tripling the size couldn't reproduce
> > +$XFS_GROWFS_PROG -D $((dblocks * 4)) $SCRATCH_MNT >>$seqres.full
> > +
> 
> Even though this is still relatively small based on what people probably
> typically test, we're still making assumptions about the size of the
> scratch device.

_require_fs_space $SCRATCH_MNT <size>

solves that problem. And in places we require 10GB of space, so a
few hundred MB isn't an issue.


-Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space

[Eryu Guan]

On Mon, Jul 21, 2014 at 09:46:38AM -0400, Brian Foster wrote:
> On Thu, Jul 17, 2014 at 12:52:33AM +0800, Eryu Guan wrote:
[snip]
> > +
> > +create_file()
> > +{
> > +	local dir=$1
> > +	local i=0
> > +
> > +	while echo -n >$dir/testfile_$i; do
> > +		let i=$i+1
> > +	done
> > +}
> > +
> > +# get standard environment, filters and checks
> > +. ./common/rc
> > +. ./common/filter
> > +
> > +# real QA test starts here
> > +_supported_fs xfs
> > +_supported_os Linux
> > +
> > +_require_scratch
> > +
> > +rm -f $seqres.full
> > +echo "Silence is golden"
> > +
> > +_scratch_mkfs_sized $((128 * 1024 * 1024)) | _filter_mkfs >$seqres.full 2>$tmp.mkfs
> > +# get original data blocks number
> > +. $tmp.mkfs
> > +_scratch_mount
> > +
> 

Hi Brian,

Thanks for the review, and sorry for the late response..

> You could probably even make this smaller and make the test quicker.
> E.g., I can create an fs down to 20M or so without any problems.  Also,
> setting imaxpct=0 might be a good idea so you don't hit that artificial
> limit.

Yes, a smaller fs could make the test much more quicker. I tested with
16M fs and the test time reduced from 70s to ~10s on my test host.

But setting imaxpct=0 could increase the total available inode number
which could make test run longer. So I tend to use default mkfs
options here.

> 
> > +# Create files to consume free inodes in background
> > +(
> > +	i=0
> > +	while [ $i -lt 1000 ]; do
> > +		mkdir $SCRATCH_MNT/testdir_$i
> > +		create_file $SCRATCH_MNT/testdir_$i &
> > +		let i=$i+1
> > +	done
> > +) >/dev/null 2>&1 &
> > +
> > +# Grow fs at the same time, at least x4
> > +# doubling or tripling the size couldn't reproduce
> > +$XFS_GROWFS_PROG -D $((dblocks * 4)) $SCRATCH_MNT >>$seqres.full
> > +
> 
> Even though this is still relatively small based on what people probably
> typically test, we're still making assumptions about the size of the
> scratch device. It may be better to create the fs as a file on TEST_DEV.
> Then you could do something like truncate to a fixed starting size, mkfs
> at ~20MB and just growfs to the full size of the file. A 4x grow at that
> point is then still only ~80MB, though hopefully it still doesn't run
> too long on slower machines.

I'll use _require_fs_space here as Dave suggested.

> 
> > +# Wait for background create_file to hit ENOSPC
> > +wait
> > +
> > +# log inode status in $seqres.full for debug purpose
> > +echo "Inode status after growing fs" >>$seqres.full
> > +$DF_PROG -i $SCRATCH_MNT >>$seqres.full
> > +
> > +# Check free inode count, we expect all free inodes are taken
> > +free_inode=`_get_free_inode $SCRATCH_MNT`
> > +if [ $free_inode -gt 0 ]; then
> > +	echo "$free_inode free inodes available, newly added space not being used"
> > +else
> > +	status=0
> > +fi
> 
> This might not be the best metric either. I believe the free inodes
> count that 'df -Ti' returns is a somewhat artificial calculation based
> on the number of free blocks available, since we can do dynamic inode
> allocation. It doesn't necessarily mean that all blocks can be allocated
> to inodes however (e.g., due to alignment or extent length constraints),
> so it might never actually read 0 unless the filesystem is perfectly
> full.
> 
> Perhaps consider something like the IUse percentage over a certain
> threshold?

I'm not sure about the proper percentage here, I'll try %99. But in my
test on RHEL6 the free inode count is always 0 after test.

Will send out v2 soon.

Thanks,
Eryu

> 
> Brian
> 
> > +
> > +exit
> > diff --git a/tests/xfs/015.out b/tests/xfs/015.out
> > new file mode 100644
> > index 0000000..fee0fcf
> > --- /dev/null
> > +++ b/tests/xfs/015.out
> > @@ -0,0 +1,2 @@
> > +QA output created by 015
> > +Silence is golden
> > diff --git a/tests/xfs/group b/tests/xfs/group
> > index d5b50b7..0aab336 100644
> > --- a/tests/xfs/group
> > +++ b/tests/xfs/group
> > @@ -12,6 +12,7 @@
> >  012 rw auto quick
> >  013 auto metadata stress
> >  014 auto enospc quick quota
> > +015 auto enospc growfs
> >  016 rw auto quick
> >  017 mount auto quick stress
> >  018 deprecated # log logprint v2log
> > -- 
> > 1.9.3
> > 
> > --
> > To unsubscribe from this list: send the line "unsubscribe fstests" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

[PATCH v2] xfs: new case to test inode allocations in post-growfs disk space

[Eryu Guan]

Make sure inodes can be allocated in new space added by xfs_growfs.

Regression test for
xfs: allow inode allocations in post-growfs disk space

Signed-off-by: Eryu Guan <eguan@redhat.com>
---
v2:
 - test on 16M xfs to make test quicker, ~70s -> ~10s
 - use _require_fs_space to check $SCRATCH_MNT space
 - reduce inode consumer count to agcount * 2, not hardcoded 1000
 - expect 99% inode usage, not absolute number 0 of free inode
 - new _get_total_inode and _get_used_inode helper, and keep
   _get_free_inode helper which could benefit other tests

 common/rc         |  33 +++++++++++++++++
 tests/xfs/015     | 105 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
 tests/xfs/015.out |   2 ++
 tests/xfs/group   |   1 +
 4 files changed, 141 insertions(+)
 create mode 100755 tests/xfs/015
 create mode 100644 tests/xfs/015.out

diff --git a/common/rc b/common/rc
index 2c83340..407fb94 100644
--- a/common/rc
+++ b/common/rc
@@ -2225,6 +2225,39 @@ _require_btrfs_fs_feature()
 		_notrun "Feature $feat not supported by the available btrfs version"
 }
 
+_get_total_inode()
+{
+	if [ -z "$1" ]; then
+		echo "Usage: _get_total_inode <mnt>"
+		exit 1
+	fi
+	local nr_inode;
+	nr_inode=`$DF_PROG -i $1 | tail -1 | awk '{print $3}'`
+	echo $nr_inode
+}
+
+_get_used_inode()
+{
+	if [ -z "$1" ]; then
+		echo "Usage: _get_used_inode <mnt>"
+		exit 1
+	fi
+	local nr_inode;
+	nr_inode=`$DF_PROG -i $1 | tail -1 | awk '{print $4}'`
+	echo $nr_inode
+}
+
+_get_free_inode()
+{
+	if [ -z "$1" ]; then
+		echo "Usage: _get_free_inode <mnt>"
+		exit 1
+	fi
+	local nr_inode;
+	nr_inode=`$DF_PROG -i $1 | tail -1 | awk '{print $5}'`
+	echo $nr_inode
+}
+
 init_rc()
 {
 	if [ "$iam" == new ]
diff --git a/tests/xfs/015 b/tests/xfs/015
new file mode 100755
index 0000000..4dbf38a
--- /dev/null
+++ b/tests/xfs/015
@@ -0,0 +1,105 @@
+#! /bin/bash
+# FS QA Test No. xfs/015
+#
+# Make sure inodes can be allocated in new space added by xfs_growfs
+#
+# Regression test for
+# xfs: allow inode allocations in post-growfs disk space
+#
+#-----------------------------------------------------------------------
+# Copyright (c) 2014 Red Hat 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
+#-----------------------------------------------------------------------
+#
+
+seq=`basename $0`
+seqres=$RESULT_DIR/$seq
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1	# failure is the default!
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+_cleanup()
+{
+    cd /
+    rm -f $tmp.*
+}
+
+create_file()
+{
+	local dir=$1
+	local i=0
+
+	while echo -n >$dir/testfile_$i; do
+		let i=$i+1
+	done
+}
+
+# get standard environment, filters and checks
+. ./common/rc
+. ./common/filter
+
+# real QA test starts here
+_supported_fs xfs
+_supported_os Linux
+
+_require_scratch
+
+# need 64M space, don't make any assumption
+_scratch_mkfs >/dev/null 2>&1
+_scratch_mount
+_require_fs_space $SCRATCH_MNT 65536
+_scratch_unmount
+
+rm -f $seqres.full
+
+_scratch_mkfs_sized $((16 * 1024 * 1024)) | _filter_mkfs >$seqres.full 2>$tmp.mkfs
+# get original data blocks number and agcount
+. $tmp.mkfs
+_scratch_mount
+
+nr_worker=$((agcount * 2))
+echo "Fork $nr_worker workers to consume free inodes in background" >>$seqres.full
+(
+	i=0
+	while [ $i -lt $nr_worker ]; do
+		mkdir $SCRATCH_MNT/testdir_$i
+		create_file $SCRATCH_MNT/testdir_$i &
+		let i=$i+1
+	done
+	wait
+) >/dev/null 2>&1 &
+
+# Grow fs at the same time, at least x4
+# doubling or tripling the size couldn't reproduce
+echo "Grow fs to $((dblocks * 4)) blocks" >>$seqres.full
+$XFS_GROWFS_PROG -D $((dblocks * 4)) $SCRATCH_MNT >>$seqres.full
+
+# Wait for background create_file to hit ENOSPC
+wait
+
+# log inode status in $seqres.full for debug purpose
+echo "Inode status after growing fs" >>$seqres.full
+$DF_PROG -i $SCRATCH_MNT >>$seqres.full
+
+# inode should be at least 99% used
+total_inode=`_get_total_inode $SCRATCH_MNT`
+used_inode=`_get_used_inode $SCRATCH_MNT`
+_within_tolerance "used inodes" $used_inode $total_inode %1 -v
+
+status=$?
+exit
diff --git a/tests/xfs/015.out b/tests/xfs/015.out
new file mode 100644
index 0000000..8275ab3
--- /dev/null
+++ b/tests/xfs/015.out
@@ -0,0 +1,2 @@
+QA output created by 015
+used inodes is in range
diff --git a/tests/xfs/group b/tests/xfs/group
index d5b50b7..0aab336 100644
--- a/tests/xfs/group
+++ b/tests/xfs/group
@@ -12,6 +12,7 @@
 012 rw auto quick
 013 auto metadata stress
 014 auto enospc quick quota
+015 auto enospc growfs
 016 rw auto quick
 017 mount auto quick stress
 018 deprecated # log logprint v2log
-- 
1.8.3.1

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space

[Brian Foster]

On Thu, Jul 24, 2014 at 06:36:58PM +0800, Eryu Guan wrote:
> On Mon, Jul 21, 2014 at 09:46:38AM -0400, Brian Foster wrote:
> > On Thu, Jul 17, 2014 at 12:52:33AM +0800, Eryu Guan wrote:
> [snip]
> > > +
> > > +create_file()
> > > +{
> > > +	local dir=$1
> > > +	local i=0
> > > +
> > > +	while echo -n >$dir/testfile_$i; do
> > > +		let i=$i+1
> > > +	done
> > > +}
> > > +
> > > +# get standard environment, filters and checks
> > > +. ./common/rc
> > > +. ./common/filter
> > > +
> > > +# real QA test starts here
> > > +_supported_fs xfs
> > > +_supported_os Linux
> > > +
> > > +_require_scratch
> > > +
> > > +rm -f $seqres.full
> > > +echo "Silence is golden"
> > > +
> > > +_scratch_mkfs_sized $((128 * 1024 * 1024)) | _filter_mkfs >$seqres.full 2>$tmp.mkfs
> > > +# get original data blocks number
> > > +. $tmp.mkfs
> > > +_scratch_mount
> > > +
> > 
> 
> Hi Brian,
> 
> Thanks for the review, and sorry for the late response..
> 
> > You could probably even make this smaller and make the test quicker.
> > E.g., I can create an fs down to 20M or so without any problems.  Also,
> > setting imaxpct=0 might be a good idea so you don't hit that artificial
> > limit.
> 
> Yes, a smaller fs could make the test much more quicker. I tested with
> 16M fs and the test time reduced from 70s to ~10s on my test host.
> 

That sounds great.

> But setting imaxpct=0 could increase the total available inode number
> which could make test run longer. So I tend to use default mkfs
> options here.
>

True... I don't really want to make a big deal out of imaxpct. I think
the consensus now is that it's a useless relic and will probably be
removed. That does mean this test will eventually use the full fs space
by default and we should make sure it runs in a reasonable amount of
time. FWIW, it seems to in my tests, running in under 2 minutes on a
single spindle.

The other issue is that if I set imaxpct=1 in my mkfs options, the test
passes. Should it? Is it actually testing what it should be in that
scenario? ;) Note that when imaxpct is set, the 'df -i' information will
be based on the cap that imaxpct sets. E.g., it will show 100% usage
even though we've only used a few MB for inodes.

Brian

> > 
> > > +# Create files to consume free inodes in background
> > > +(
> > > +	i=0
> > > +	while [ $i -lt 1000 ]; do
> > > +		mkdir $SCRATCH_MNT/testdir_$i
> > > +		create_file $SCRATCH_MNT/testdir_$i &
> > > +		let i=$i+1
> > > +	done
> > > +) >/dev/null 2>&1 &
> > > +
> > > +# Grow fs at the same time, at least x4
> > > +# doubling or tripling the size couldn't reproduce
> > > +$XFS_GROWFS_PROG -D $((dblocks * 4)) $SCRATCH_MNT >>$seqres.full
> > > +
> > 
> > Even though this is still relatively small based on what people probably
> > typically test, we're still making assumptions about the size of the
> > scratch device. It may be better to create the fs as a file on TEST_DEV.
> > Then you could do something like truncate to a fixed starting size, mkfs
> > at ~20MB and just growfs to the full size of the file. A 4x grow at that
> > point is then still only ~80MB, though hopefully it still doesn't run
> > too long on slower machines.
> 
> I'll use _require_fs_space here as Dave suggested.
> 
> > 
> > > +# Wait for background create_file to hit ENOSPC
> > > +wait
> > > +
> > > +# log inode status in $seqres.full for debug purpose
> > > +echo "Inode status after growing fs" >>$seqres.full
> > > +$DF_PROG -i $SCRATCH_MNT >>$seqres.full
> > > +
> > > +# Check free inode count, we expect all free inodes are taken
> > > +free_inode=`_get_free_inode $SCRATCH_MNT`
> > > +if [ $free_inode -gt 0 ]; then
> > > +	echo "$free_inode free inodes available, newly added space not being used"
> > > +else
> > > +	status=0
> > > +fi
> > 
> > This might not be the best metric either. I believe the free inodes
> > count that 'df -Ti' returns is a somewhat artificial calculation based
> > on the number of free blocks available, since we can do dynamic inode
> > allocation. It doesn't necessarily mean that all blocks can be allocated
> > to inodes however (e.g., due to alignment or extent length constraints),
> > so it might never actually read 0 unless the filesystem is perfectly
> > full.
> > 
> > Perhaps consider something like the IUse percentage over a certain
> > threshold?
> 
> I'm not sure about the proper percentage here, I'll try %99. But in my
> test on RHEL6 the free inode count is always 0 after test.
> 
> Will send out v2 soon.
> 
> Thanks,
> Eryu
> 
> > 
> > Brian
> > 
> > > +
> > > +exit
> > > diff --git a/tests/xfs/015.out b/tests/xfs/015.out
> > > new file mode 100644
> > > index 0000000..fee0fcf
> > > --- /dev/null
> > > +++ b/tests/xfs/015.out
> > > @@ -0,0 +1,2 @@
> > > +QA output created by 015
> > > +Silence is golden
> > > diff --git a/tests/xfs/group b/tests/xfs/group
> > > index d5b50b7..0aab336 100644
> > > --- a/tests/xfs/group
> > > +++ b/tests/xfs/group
> > > @@ -12,6 +12,7 @@
> > >  012 rw auto quick
> > >  013 auto metadata stress
> > >  014 auto enospc quick quota
> > > +015 auto enospc growfs
> > >  016 rw auto quick
> > >  017 mount auto quick stress
> > >  018 deprecated # log logprint v2log
> > > -- 
> > > 1.9.3
> > > 
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe fstests" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > 
> > _______________________________________________
> > xfs mailing list
> > xfs@oss.sgi.com
> > http://oss.sgi.com/mailman/listinfo/xfs
> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space

[Eryu Guan]

On Thu, Jul 24, 2014 at 09:06:47AM -0400, Brian Foster wrote:
> On Thu, Jul 24, 2014 at 06:36:58PM +0800, Eryu Guan wrote:
> > On Mon, Jul 21, 2014 at 09:46:38AM -0400, Brian Foster wrote:
> > > On Thu, Jul 17, 2014 at 12:52:33AM +0800, Eryu Guan wrote:
> > [snip]
> > > > +
> > > > +create_file()
> > > > +{
> > > > +	local dir=$1
> > > > +	local i=0
> > > > +
> > > > +	while echo -n >$dir/testfile_$i; do
> > > > +		let i=$i+1
> > > > +	done
> > > > +}
> > > > +
> > > > +# get standard environment, filters and checks
> > > > +. ./common/rc
> > > > +. ./common/filter
> > > > +
> > > > +# real QA test starts here
> > > > +_supported_fs xfs
> > > > +_supported_os Linux
> > > > +
> > > > +_require_scratch
> > > > +
> > > > +rm -f $seqres.full
> > > > +echo "Silence is golden"
> > > > +
> > > > +_scratch_mkfs_sized $((128 * 1024 * 1024)) | _filter_mkfs >$seqres.full 2>$tmp.mkfs
> > > > +# get original data blocks number
> > > > +. $tmp.mkfs
> > > > +_scratch_mount
> > > > +
> > > 
> > 
> > Hi Brian,
> > 
> > Thanks for the review, and sorry for the late response..
> > 
> > > You could probably even make this smaller and make the test quicker.
> > > E.g., I can create an fs down to 20M or so without any problems.  Also,
> > > setting imaxpct=0 might be a good idea so you don't hit that artificial
> > > limit.
> > 
> > Yes, a smaller fs could make the test much more quicker. I tested with
> > 16M fs and the test time reduced from 70s to ~10s on my test host.
> > 
> 
> That sounds great.
> 
> > But setting imaxpct=0 could increase the total available inode number
> > which could make test run longer. So I tend to use default mkfs
> > options here.
> >
> 
> True... I don't really want to make a big deal out of imaxpct. I think
> the consensus now is that it's a useless relic and will probably be
> removed. That does mean this test will eventually use the full fs space
> by default and we should make sure it runs in a reasonable amount of
> time. FWIW, it seems to in my tests, running in under 2 minutes on a
> single spindle.
> 
> The other issue is that if I set imaxpct=1 in my mkfs options, the test
> passes. Should it? Is it actually testing what it should be in that
> scenario? ;) Note that when imaxpct is set, the 'df -i' information will
> be based on the cap that imaxpct sets. E.g., it will show 100% usage
> even though we've only used a few MB for inodes.

Yes, I can pass the test too with imaxpct=1 set. But I'm not really
sure about imaxpct impact on the test result.

Eric, do you have any suggestions here? Because I saw you send out the
kernel patch to fix this problem :)

Thanks,
Eryu
> 
> Brian
> 
> > > 
> > > > +# Create files to consume free inodes in background
> > > > +(
> > > > +	i=0
> > > > +	while [ $i -lt 1000 ]; do
> > > > +		mkdir $SCRATCH_MNT/testdir_$i
> > > > +		create_file $SCRATCH_MNT/testdir_$i &
> > > > +		let i=$i+1
> > > > +	done
> > > > +) >/dev/null 2>&1 &
> > > > +
> > > > +# Grow fs at the same time, at least x4
> > > > +# doubling or tripling the size couldn't reproduce
> > > > +$XFS_GROWFS_PROG -D $((dblocks * 4)) $SCRATCH_MNT >>$seqres.full
> > > > +
> > > 
> > > Even though this is still relatively small based on what people probably
> > > typically test, we're still making assumptions about the size of the
> > > scratch device. It may be better to create the fs as a file on TEST_DEV.
> > > Then you could do something like truncate to a fixed starting size, mkfs
> > > at ~20MB and just growfs to the full size of the file. A 4x grow at that
> > > point is then still only ~80MB, though hopefully it still doesn't run
> > > too long on slower machines.
> > 
> > I'll use _require_fs_space here as Dave suggested.
> > 
> > > 
> > > > +# Wait for background create_file to hit ENOSPC
> > > > +wait
> > > > +
> > > > +# log inode status in $seqres.full for debug purpose
> > > > +echo "Inode status after growing fs" >>$seqres.full
> > > > +$DF_PROG -i $SCRATCH_MNT >>$seqres.full
> > > > +
> > > > +# Check free inode count, we expect all free inodes are taken
> > > > +free_inode=`_get_free_inode $SCRATCH_MNT`
> > > > +if [ $free_inode -gt 0 ]; then
> > > > +	echo "$free_inode free inodes available, newly added space not being used"
> > > > +else
> > > > +	status=0
> > > > +fi
> > > 
> > > This might not be the best metric either. I believe the free inodes
> > > count that 'df -Ti' returns is a somewhat artificial calculation based
> > > on the number of free blocks available, since we can do dynamic inode
> > > allocation. It doesn't necessarily mean that all blocks can be allocated
> > > to inodes however (e.g., due to alignment or extent length constraints),
> > > so it might never actually read 0 unless the filesystem is perfectly
> > > full.
> > > 
> > > Perhaps consider something like the IUse percentage over a certain
> > > threshold?
> > 
> > I'm not sure about the proper percentage here, I'll try %99. But in my
> > test on RHEL6 the free inode count is always 0 after test.
> > 
> > Will send out v2 soon.
> > 
> > Thanks,
> > Eryu
> > 
> > > 
> > > Brian
> > > 
> > > > +
> > > > +exit
> > > > diff --git a/tests/xfs/015.out b/tests/xfs/015.out
> > > > new file mode 100644
> > > > index 0000000..fee0fcf
> > > > --- /dev/null
> > > > +++ b/tests/xfs/015.out
> > > > @@ -0,0 +1,2 @@
> > > > +QA output created by 015
> > > > +Silence is golden
> > > > diff --git a/tests/xfs/group b/tests/xfs/group
> > > > index d5b50b7..0aab336 100644
> > > > --- a/tests/xfs/group
> > > > +++ b/tests/xfs/group
> > > > @@ -12,6 +12,7 @@
> > > >  012 rw auto quick
> > > >  013 auto metadata stress
> > > >  014 auto enospc quick quota
> > > > +015 auto enospc growfs
> > > >  016 rw auto quick
> > > >  017 mount auto quick stress
> > > >  018 deprecated # log logprint v2log
> > > > -- 
> > > > 1.9.3
> > > > 
> > > > --
> > > > To unsubscribe from this list: send the line "unsubscribe fstests" in
> > > > the body of a message to majordomo@vger.kernel.org
> > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > 
> > > _______________________________________________
> > > xfs mailing list
> > > xfs@oss.sgi.com
> > > http://oss.sgi.com/mailman/listinfo/xfs
> > --
> > To unsubscribe from this list: send the line "unsubscribe fstests" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space

[Brian Foster]

On Thu, Jul 31, 2014 at 11:32:38AM +0800, Eryu Guan wrote:
> On Thu, Jul 24, 2014 at 09:06:47AM -0400, Brian Foster wrote:
> > On Thu, Jul 24, 2014 at 06:36:58PM +0800, Eryu Guan wrote:
> > > On Mon, Jul 21, 2014 at 09:46:38AM -0400, Brian Foster wrote:
> > > > On Thu, Jul 17, 2014 at 12:52:33AM +0800, Eryu Guan wrote:
> > > [snip]
> > > > > +
> > > > > +create_file()
> > > > > +{
> > > > > +	local dir=$1
> > > > > +	local i=0
> > > > > +
> > > > > +	while echo -n >$dir/testfile_$i; do
> > > > > +		let i=$i+1
> > > > > +	done
> > > > > +}
> > > > > +
> > > > > +# get standard environment, filters and checks
> > > > > +. ./common/rc
> > > > > +. ./common/filter
> > > > > +
> > > > > +# real QA test starts here
> > > > > +_supported_fs xfs
> > > > > +_supported_os Linux
> > > > > +
> > > > > +_require_scratch
> > > > > +
> > > > > +rm -f $seqres.full
> > > > > +echo "Silence is golden"
> > > > > +
> > > > > +_scratch_mkfs_sized $((128 * 1024 * 1024)) | _filter_mkfs >$seqres.full 2>$tmp.mkfs
> > > > > +# get original data blocks number
> > > > > +. $tmp.mkfs
> > > > > +_scratch_mount
> > > > > +
> > > > 
> > > 
> > > Hi Brian,
> > > 
> > > Thanks for the review, and sorry for the late response..
> > > 
> > > > You could probably even make this smaller and make the test quicker.
> > > > E.g., I can create an fs down to 20M or so without any problems.  Also,
> > > > setting imaxpct=0 might be a good idea so you don't hit that artificial
> > > > limit.
> > > 
> > > Yes, a smaller fs could make the test much more quicker. I tested with
> > > 16M fs and the test time reduced from 70s to ~10s on my test host.
> > > 
> > 
> > That sounds great.
> > 
> > > But setting imaxpct=0 could increase the total available inode number
> > > which could make test run longer. So I tend to use default mkfs
> > > options here.
> > >
> > 
> > True... I don't really want to make a big deal out of imaxpct. I think
> > the consensus now is that it's a useless relic and will probably be
> > removed. That does mean this test will eventually use the full fs space
> > by default and we should make sure it runs in a reasonable amount of
> > time. FWIW, it seems to in my tests, running in under 2 minutes on a
> > single spindle.
> > 
> > The other issue is that if I set imaxpct=1 in my mkfs options, the test
> > passes. Should it? Is it actually testing what it should be in that
> > scenario? ;) Note that when imaxpct is set, the 'df -i' information will
> > be based on the cap that imaxpct sets. E.g., it will show 100% usage
> > even though we've only used a few MB for inodes.
> 
> Yes, I can pass the test too with imaxpct=1 set. But I'm not really
> sure about imaxpct impact on the test result.
> 
> Eric, do you have any suggestions here? Because I saw you send out the
> kernel patch to fix this problem :)
> 

(I think Eric might be away.)

To be clear, I'm just suggesting we verify whether the test is as
focused as possible. Put another way, have we verified whether this test
detects the problem with this potential configuration? E.g., run a
kernel without Eric's growfs fix, run the test and verify it fails.
Repeat with '-i imaxpct=1' in MKFS_OPTIONS and verify the test still
fails. If it does, then it's probably fine. If it passes, that's a hole
in the test case we should close up.

Brian

> Thanks,
> Eryu
> > 
> > Brian
> > 
> > > > 
> > > > > +# Create files to consume free inodes in background
> > > > > +(
> > > > > +	i=0
> > > > > +	while [ $i -lt 1000 ]; do
> > > > > +		mkdir $SCRATCH_MNT/testdir_$i
> > > > > +		create_file $SCRATCH_MNT/testdir_$i &
> > > > > +		let i=$i+1
> > > > > +	done
> > > > > +) >/dev/null 2>&1 &
> > > > > +
> > > > > +# Grow fs at the same time, at least x4
> > > > > +# doubling or tripling the size couldn't reproduce
> > > > > +$XFS_GROWFS_PROG -D $((dblocks * 4)) $SCRATCH_MNT >>$seqres.full
> > > > > +
> > > > 
> > > > Even though this is still relatively small based on what people probably
> > > > typically test, we're still making assumptions about the size of the
> > > > scratch device. It may be better to create the fs as a file on TEST_DEV.
> > > > Then you could do something like truncate to a fixed starting size, mkfs
> > > > at ~20MB and just growfs to the full size of the file. A 4x grow at that
> > > > point is then still only ~80MB, though hopefully it still doesn't run
> > > > too long on slower machines.
> > > 
> > > I'll use _require_fs_space here as Dave suggested.
> > > 
> > > > 
> > > > > +# Wait for background create_file to hit ENOSPC
> > > > > +wait
> > > > > +
> > > > > +# log inode status in $seqres.full for debug purpose
> > > > > +echo "Inode status after growing fs" >>$seqres.full
> > > > > +$DF_PROG -i $SCRATCH_MNT >>$seqres.full
> > > > > +
> > > > > +# Check free inode count, we expect all free inodes are taken
> > > > > +free_inode=`_get_free_inode $SCRATCH_MNT`
> > > > > +if [ $free_inode -gt 0 ]; then
> > > > > +	echo "$free_inode free inodes available, newly added space not being used"
> > > > > +else
> > > > > +	status=0
> > > > > +fi
> > > > 
> > > > This might not be the best metric either. I believe the free inodes
> > > > count that 'df -Ti' returns is a somewhat artificial calculation based
> > > > on the number of free blocks available, since we can do dynamic inode
> > > > allocation. It doesn't necessarily mean that all blocks can be allocated
> > > > to inodes however (e.g., due to alignment or extent length constraints),
> > > > so it might never actually read 0 unless the filesystem is perfectly
> > > > full.
> > > > 
> > > > Perhaps consider something like the IUse percentage over a certain
> > > > threshold?
> > > 
> > > I'm not sure about the proper percentage here, I'll try %99. But in my
> > > test on RHEL6 the free inode count is always 0 after test.
> > > 
> > > Will send out v2 soon.
> > > 
> > > Thanks,
> > > Eryu
> > > 
> > > > 
> > > > Brian
> > > > 
> > > > > +
> > > > > +exit
> > > > > diff --git a/tests/xfs/015.out b/tests/xfs/015.out
> > > > > new file mode 100644
> > > > > index 0000000..fee0fcf
> > > > > --- /dev/null
> > > > > +++ b/tests/xfs/015.out
> > > > > @@ -0,0 +1,2 @@
> > > > > +QA output created by 015
> > > > > +Silence is golden
> > > > > diff --git a/tests/xfs/group b/tests/xfs/group
> > > > > index d5b50b7..0aab336 100644
> > > > > --- a/tests/xfs/group
> > > > > +++ b/tests/xfs/group
> > > > > @@ -12,6 +12,7 @@
> > > > >  012 rw auto quick
> > > > >  013 auto metadata stress
> > > > >  014 auto enospc quick quota
> > > > > +015 auto enospc growfs
> > > > >  016 rw auto quick
> > > > >  017 mount auto quick stress
> > > > >  018 deprecated # log logprint v2log
> > > > > -- 
> > > > > 1.9.3
> > > > > 
> > > > > --
> > > > > To unsubscribe from this list: send the line "unsubscribe fstests" in
> > > > > the body of a message to majordomo@vger.kernel.org
> > > > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > > > 
> > > > _______________________________________________
> > > > xfs mailing list
> > > > xfs@oss.sgi.com
> > > > http://oss.sgi.com/mailman/listinfo/xfs
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe fstests" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > --
> > To unsubscribe from this list: send the line "unsubscribe fstests" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe fstests" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space

[Eryu Guan]

On Thu, Jul 31, 2014 at 07:45:37AM -0400, Brian Foster wrote:
> On Thu, Jul 31, 2014 at 11:32:38AM +0800, Eryu Guan wrote:
> > On Thu, Jul 24, 2014 at 09:06:47AM -0400, Brian Foster wrote:
> > > On Thu, Jul 24, 2014 at 06:36:58PM +0800, Eryu Guan wrote:
> > > > On Mon, Jul 21, 2014 at 09:46:38AM -0400, Brian Foster wrote:
> > > > > On Thu, Jul 17, 2014 at 12:52:33AM +0800, Eryu Guan wrote:
[snip]
> > > > Hi Brian,
> > > > 
> > > > Thanks for the review, and sorry for the late response..
> > > > 
> > > > > You could probably even make this smaller and make the test quicker.
> > > > > E.g., I can create an fs down to 20M or so without any problems.  Also,
> > > > > setting imaxpct=0 might be a good idea so you don't hit that artificial
> > > > > limit.
> > > > 
> > > > Yes, a smaller fs could make the test much more quicker. I tested with
> > > > 16M fs and the test time reduced from 70s to ~10s on my test host.
> > > > 
> > > 
> > > That sounds great.
> > > 
> > > > But setting imaxpct=0 could increase the total available inode number
> > > > which could make test run longer. So I tend to use default mkfs
> > > > options here.
> > > >
> > > 
> > > True... I don't really want to make a big deal out of imaxpct. I think
> > > the consensus now is that it's a useless relic and will probably be
> > > removed. That does mean this test will eventually use the full fs space
> > > by default and we should make sure it runs in a reasonable amount of
> > > time. FWIW, it seems to in my tests, running in under 2 minutes on a
> > > single spindle.
> > > 
> > > The other issue is that if I set imaxpct=1 in my mkfs options, the test
> > > passes. Should it? Is it actually testing what it should be in that
> > > scenario? ;) Note that when imaxpct is set, the 'df -i' information will
> > > be based on the cap that imaxpct sets. E.g., it will show 100% usage
> > > even though we've only used a few MB for inodes.
> > 
> > Yes, I can pass the test too with imaxpct=1 set. But I'm not really
> > sure about imaxpct impact on the test result.
> > 
> > Eric, do you have any suggestions here? Because I saw you send out the
> > kernel patch to fix this problem :)
> > 
> 
> (I think Eric might be away.)
> 
> To be clear, I'm just suggesting we verify whether the test is as
> focused as possible. Put another way, have we verified whether this test
> detects the problem with this potential configuration? E.g., run a
> kernel without Eric's growfs fix, run the test and verify it fails.
> Repeat with '-i imaxpct=1' in MKFS_OPTIONS and verify the test still
> fails. If it does, then it's probably fine. If it passes, that's a hole
> in the test case we should close up.
> 
> Brian

Thanks Brian, I'll look into it and try to work it out.

(Note that with my v2 patch, the maxpct number in question is 5 instead of 1)

Thanks,
Eryu

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs