* [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space @ 2014-07-16 16:52 Eryu Guan 2014-07-21 13:46 ` Brian Foster 2014-07-24 10:51 ` [PATCH v2] " Eryu Guan 0 siblings, 2 replies; 9+ messages in thread From: Eryu Guan @ 2014-07-16 16:52 UTC (permalink / raw) To: fstests; +Cc: Eric Sandeen, Eryu Guan, Boris Ranto, xfs 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space 2014-07-16 16:52 [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space Eryu Guan @ 2014-07-21 13:46 ` Brian Foster 2014-07-22 0:23 ` Dave Chinner 2014-07-24 10:36 ` Eryu Guan 2014-07-24 10:51 ` [PATCH v2] " Eryu Guan 1 sibling, 2 replies; 9+ messages in thread From: Brian Foster @ 2014-07-21 13:46 UTC (permalink / raw) To: Eryu Guan; +Cc: Boris Ranto, Eric Sandeen, fstests, xfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space 2014-07-21 13:46 ` Brian Foster @ 2014-07-22 0:23 ` Dave Chinner 2014-07-24 10:36 ` Eryu Guan 1 sibling, 0 replies; 9+ messages in thread From: Dave Chinner @ 2014-07-22 0:23 UTC (permalink / raw) To: Brian Foster; +Cc: fstests, xfs, Eryu Guan, Boris Ranto, Eric Sandeen 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space 2014-07-21 13:46 ` Brian Foster 2014-07-22 0:23 ` Dave Chinner @ 2014-07-24 10:36 ` Eryu Guan 2014-07-24 13:06 ` Brian Foster 1 sibling, 1 reply; 9+ messages in thread From: Eryu Guan @ 2014-07-24 10:36 UTC (permalink / raw) To: Brian Foster; +Cc: fstests, xfs, Eryu Guan, Boris Ranto, Eric Sandeen 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space 2014-07-24 10:36 ` Eryu Guan @ 2014-07-24 13:06 ` Brian Foster 2014-07-31 3:32 ` Eryu Guan 0 siblings, 1 reply; 9+ messages in thread From: Brian Foster @ 2014-07-24 13:06 UTC (permalink / raw) To: Eryu Guan; +Cc: fstests, xfs, Eryu Guan, Boris Ranto, Eric Sandeen 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space 2014-07-24 13:06 ` Brian Foster @ 2014-07-31 3:32 ` Eryu Guan 2014-07-31 11:45 ` Brian Foster 0 siblings, 1 reply; 9+ messages in thread From: Eryu Guan @ 2014-07-31 3:32 UTC (permalink / raw) To: Brian Foster; +Cc: fstests, Eryu Guan, Eric Sandeen, Boris Ranto, xfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space 2014-07-31 3:32 ` Eryu Guan @ 2014-07-31 11:45 ` Brian Foster 2014-07-31 12:42 ` Eryu Guan 0 siblings, 1 reply; 9+ messages in thread From: Brian Foster @ 2014-07-31 11:45 UTC (permalink / raw) To: Eryu Guan; +Cc: fstests, Eryu Guan, Eric Sandeen, Boris Ranto, xfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space 2014-07-31 11:45 ` Brian Foster @ 2014-07-31 12:42 ` Eryu Guan 0 siblings, 0 replies; 9+ messages in thread From: Eryu Guan @ 2014-07-31 12:42 UTC (permalink / raw) To: Brian Foster; +Cc: Boris Ranto, Eryu Guan, Eric Sandeen, fstests, xfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v2] xfs: new case to test inode allocations in post-growfs disk space 2014-07-16 16:52 [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space Eryu Guan 2014-07-21 13:46 ` Brian Foster @ 2014-07-24 10:51 ` Eryu Guan 1 sibling, 0 replies; 9+ messages in thread From: Eryu Guan @ 2014-07-24 10:51 UTC (permalink / raw) To: fstests; +Cc: Eryu Guan, xfs 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 ^ permalink raw reply related [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-07-31 12:42 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-07-16 16:52 [PATCH 1/2] xfs: new case to test inode allocations in post-growfs disk space Eryu Guan 2014-07-21 13:46 ` Brian Foster 2014-07-22 0:23 ` Dave Chinner 2014-07-24 10:36 ` Eryu Guan 2014-07-24 13:06 ` Brian Foster 2014-07-31 3:32 ` Eryu Guan 2014-07-31 11:45 ` Brian Foster 2014-07-31 12:42 ` Eryu Guan 2014-07-24 10:51 ` [PATCH v2] " Eryu Guan
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox