On Mon, Oct 16, 2017 at 09:57:11AM +0300, Nikolay Borisov wrote: > > > On 13.10.2017 21:08, Liu Bo wrote: > > On Thu, Oct 12, 2017 at 03:06:57PM +0800, Eryu Guan wrote: > >> On Mon, Oct 09, 2017 at 11:39:21AM -0600, Liu Bo wrote: > >>> Currently running 'btrfs device delete' can end up with losing data raid > >>> profile (if any), this test is to reproduce the problem. > >>> > >>> The fix is > >>> "Btrfs: avoid losing data raid profile when deleting a device" > >>> > >>> Signed-off-by: Liu Bo <bo.li....@oracle.com> > >>> --- > >>> tests/btrfs/151 | 73 > >>> +++++++++++++++++++++++++++++++++++++++++++++++++++++ > >>> tests/btrfs/151.out | 2 ++ > >>> tests/btrfs/group | 1 + > >>> 3 files changed, 76 insertions(+) > >>> create mode 100755 tests/btrfs/151 > >>> create mode 100644 tests/btrfs/151.out > >>> > >>> diff --git a/tests/btrfs/151 b/tests/btrfs/151 > >>> new file mode 100755 > >>> index 0000000..1866cb6 > >>> --- /dev/null > >>> +++ b/tests/btrfs/151 > >>> @@ -0,0 +1,73 @@ > >>> +#! /bin/bash > >>> +# FS QA Test 151 > >>> +# > >>> +# Test if it's losing data chunk's raid profile after 'btrfs device > >>> +# remove'. > >>> +# > >>> +# The fix is > >>> +# Btrfs: avoid losing data raid profile when deleting a device > >>> +# > >>> +#----------------------------------------------------------------------- > >>> +# Copyright (c) 2017 Oracle. 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.* > >>> +} > >>> + > >>> +# get standard environment, filters and checks > >>> +. ./common/rc > >>> +. ./common/filter > >>> + > >>> +# remove previous $seqres.full before test > >>> +rm -f $seqres.full > >>> + > >>> +# real QA test starts here > >>> + > >>> +# Modify as appropriate. > >>> +_supported_fs btrfs > >>> +_supported_os Linux > >>> +_require_scratch > >> > >> Better to have _require_btrfs_dev_del_by_devid too. > >> > > > > OK. > > > >>> +_require_scratch_dev_pool 3 > >> > >> Hmm, this only reproduces for me if I have exact three devices in > >> SCRATCH_DEV_POOL, large dev pool passed the test. If this can only be > >> reproduced with a three-device setup, I think we need to limit the dev > >> pool size to at most 3, e.g. > >> > >> # <comments about why we need exact 3 devices> > >> _scratch_dev_pool_get 3 > >> <do test here> > >> _scratch_dev_pool_put > >> status=0 > >> exit > > > > Oops, you're totally right. > > > >> > >>> + > >>> +# create raid1 for data > >>> +_scratch_pool_mkfs "-d raid1 -b 1G" >> $seqres.full 2>&1 > >>> + > >>> +# we need an empty data chunk, so nospace_cache is required. > >>> +_scratch_mount -onospace_cache > >>> + > >>> +# if data chunk is empty, 'btrfs device remove' can change raid1 to > >>> +# single. > >>> +$BTRFS_UTIL_PROG device delete 2 $SCRATCH_MNT >> $seqres.full > >>> + > >>> +df_ret=`$BTRFS_UTIL_PROG filesystem df $SCRATCH_MNT` > >>> +echo $df_ret | $AWK_PROG -F ':' '/Data,/ {print $1}' > >> > >> I'd like to avoid saving outputs in a variable, it's easy to cause > >> subtle problems without proper quoting, as Dave found out in this thread > >> > >> [whacky issue] xfs/277 endlessly looping in _require_xfs_io_command > >> http://www.spinics.net/lists/fstests/msg07501.html > >> > >> How about: > >> > >> # save btrfs filesystem df output for debug purpose > >> $BTRFS_UTIL_PROG filesystem df $SCRATCH_MNT >>$seqres.full 2>&1 > >> $BTRFS_UTIL_PROG filesystem df $SCRATCH_MNT | \ > >> $AWK_PROG -F ':' '/Data,/ {print $1}' > > > > That makes sense to me, will update it. > > Also instead of invoking fi df twice and running the risk of something > changing (you never know), how about using tee? >
Sounds good, will update it. Thanks, -liubo > > > > Thanks for the comments. > > > > thanks, > > > > -liubo > > > >> > >> Thanks, > >> Eryu > >> > >>> + > >>> +# success, all done > >>> +status=0 > >>> +exit > >>> diff --git a/tests/btrfs/151.out b/tests/btrfs/151.out > >>> new file mode 100644 > >>> index 0000000..0a1de06 > >>> --- /dev/null > >>> +++ b/tests/btrfs/151.out > >>> @@ -0,0 +1,2 @@ > >>> +QA output created by 151 > >>> +Data, RAID1 > >>> diff --git a/tests/btrfs/group b/tests/btrfs/group > >>> index e73bb1b..a7ff7b0 100644 > >>> --- a/tests/btrfs/group > >>> +++ b/tests/btrfs/group > >>> @@ -153,3 +153,4 @@ > >>> 148 auto quick rw > >>> 149 auto quick send compress > >>> 150 auto quick dangerous > >>> +151 auto quick > >>> -- > >>> 2.5.0 > >>> > >>> -- > >>> To unsubscribe from this list: send the line "unsubscribe fstests" in > >>> the body of a message to majord...@vger.kernel.org > >>> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > > the body of a message to majord...@vger.kernel.org > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html