From: Anand Jain <anand.jain@oracle.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-fsdevel@vger.kernel.org, linux-btrfs@vger.kernel.org,
xfs@oss.sgi.com, david@fromorbit.com
Subject: Re: [PATCH 1/3] 264: Functional test case for the btrfs snapshot
Date: Thu, 20 Oct 2011 23:31:55 +0800 [thread overview]
Message-ID: <4EA03EEB.3020403@oracle.com> (raw)
In-Reply-To: <20111019094209.GB3083@infradead.org>
comments in line.
On 19/10/2011 17:42, Christoph Hellwig wrote:
> On Tue, Oct 18, 2011 at 02:28:54PM +0800, Anand Jain wrote:
>> Create snapshots in various ways, modify the data around the block and
>> file boundaries and verify the data integrity.
>
> The test itselt looks good enough, but I have some comments on the
> pool infrastructure changes. I also think they should probably be
> a separate preparatory patch, or at least documented in the changelog
> as well.
>
>> index 5367be6..7c135c7 100644
>> --- a/README
>> +++ b/README
>> @@ -36,12 +36,17 @@ Preparing system for tests (IRIX and Linux):
>> not be run.
>>
>> (these must be two DIFFERENT partitions)
>> +
>> + - for btrfs only: some tests would need 3 or more independent SCRATCH disks,
>> + which should be setenv SCRATCH_DEV_POOL instead of SCRATCH_DEV
>> +
>>
>> - setup your environment
>> - setenv TEST_DEV "device containing TEST PARTITION"
>> - setenv TEST_DIR "mount point of TEST PARTITION"
>> - optionally:
>> - setenv SCRATCH_DEV "device containing SCRATCH PARTITION"
>> + - setenv SCRATCH_DEV_POOL "pool of SCRATCH disks for testing btrfs"
>
> How does one find out what the pool name is? You'll also need to
> document how to create the pool from disks.
>
agreed.
>> @@ -229,6 +229,20 @@ if [ ! -d "$TEST_DIR" ]; then
>> exit 1
>> fi
>>
>> +# a btrfs tester will set only SCRATCH_DEV_POOL, we will put first of its dev
>> +# to SCRATCH_DEV and rest to SCRATCH_DEV_POOL to maintain the backward compatibility
>> +if [ "$HOSTOS" == "Linux" ]; then
>> + FSTYP_tmp=`blkid -c /dev/null -s TYPE -o value $TEST_DEV`
>> +else
>> + FSTYP_tmp=xfs
>> +fi
>
> Why do we need a second FSTYP detection? If the existing one isn't
> early enough make sure it's done early enough instead of duplicating
> it.
looks like its ok not to have FSTYP checked here, it will follow the
following logic..
btrfs FS OR any FS
SCRATCH_DEV_POOL is unset and SCRATCH_DEV is set
. test-case with _require_scratch_dev_pool will not run
. test-case without _require_scratch_dev_pool will run
SCRATCH_DEV_POOL is set and SCRATCH_DEV is unset
. test-case with _require_scratch_dev_pool
- runs only if FSTYP=btrfs
. test-case without _require_scratch_dev_pool will run using first
dev in the SCRATCH_DEV_POOL as a SCRATCH_DEV
- if FSTYP=btrfs it includes SCRATCH_DEV_POOL disks to the FS
- if FSTYP=non-btrfs SCRATCH_DEV_POOL is ignored
SCRATCH_DEV_POOL is set and SCRATCH_DEV is set
. reports error in the config
SCRATCH_DEV_POOL is unset and SCRATCH_DEV is unset
. no change
>> --- a/common.rc
>> +++ b/common.rc
>> @@ -1498,7 +1498,11 @@ _nfiles()
>> file=f$f
>> echo > $file
>> if [ $size -gt 0 ]; then
>> - dd if=/dev/zero of=$file bs=1024 count=$size
>> + if [ $randomdata == false ]; then
>> + dd if=/dev/zero of=$file bs=1024 count=$size 2>&1 | _filter_dd
>> + else
>> + dd if=/dev/urandom of=$file bs=1024 count=$size 2>&1 | _filter_dd
>> + fi
>
> I'd rather see the randomdata flag passed down explicitly to _descend and
> _nfiles rather than setting a magic environment variable.
makes sense. added.
>> @@ -1508,7 +1512,11 @@ _nfiles()
>> _descend()
>> {
>> dirname=$1; depth=$2
>> - mkdir $dirname || die "mkdir $dirname failed"
>> + if [ -d $dirname ]; then
>> + dirname=`mktemp -dq $dirname/dir.XXXXXX`
>> + else
>> + mkdir $dirname || die "mkdir $dirname failed"
>> + fi
>
> Why would the directory here already exist? This at least needs
> very good documentation. Also the indentation seems off compared
> to the surrounding code.
Hmm. Changing this back to the original design - where calling
function has to ensure a new directory name which does not exists.
>> @@ -1550,6 +1559,7 @@ _populate_fs()
>> s) size=$OPTARG;;
>> v) verbose=true;;
>> r) root=$OPTARG;;
>> + x) randomdata=true;;
>
> indendation is off again.
oh! thks for pointing.
>> +# scratch_dev_pool should contain the disks pool for the btrfs raid
>> +_require_scratch_dev_pool()
>> +{
>> + local i
>> + case "$FSTYP" in
>> + btrfs)
>> + if [ -z "$SCRATCH_DEV_POOL" ]
>> + then
>
> For new code I'd generally prefer the more readable
>
> if [ ... ]; then
>
> although the above form unfortunately still is fairly common in
> xfsprogs.
got it.
>> +# We will check if the device is virtual (eg: loop device) since it does not
>> +# have the delete entry-point. Otherwise SCSI and USB devices are fine.
>> +_require_deletable_scratch_dev_pool()
>> +{
>> + local i
>> + local x
>> + for i in $SCRATCH_DEV_POOL; do
>> + x=`echo $i | cut -d"/" -f 3`
>> + ls -l /sys/class/block/${x} | grep -q "virtual"
>> + if [ $? == "0" ]; then
>> + _notrun "$i is a virtual device which is not deletable"
>> + fi
>> + done
>> +}
>> +
>> +# arg 1 is dev to remove and is output of the below eg.
>> +# ls -l /sys/class/block/sdd | rev | cut -d "/" -f 3 | rev
>> +_devmgt_remove()
>> +{
>> + echo 1 > /sys/class/scsi_device/${1}/device/delete || _fail "Remove disk failed"
>> +}
>> +
>> +# arg 1 is dev to add and is output of the below eg.
>> +# ls -l /sys/class/block/sdd | rev | cut -d "/" -f 3 | rev
>> +_devmgt_add()
>> +{
>> + local h
>> + local tdl
>> + # arg 1 will be in h:t:d:l format now in the h and "t d l" format
>> + h=`echo ${1} | cut -d":" -f 1`
>> + tdl=`echo ${1} | cut -d":" -f 2-|sed 's/:/ /g'`
>> +
>> + echo ${tdl} > /sys/class/scsi_host/host${h}/scan || _fail "Add disk failed"
>> +}
>
> This code looks a bit fragile to me, but I think we can fix it on the go
> if we encouter issues.
ok.
>> diff --git a/group b/group
>> index 2a8970c..cfbae8c 100644
>> --- a/group
>> +++ b/group
>> @@ -377,3 +377,4 @@ deprecated
>> 261 auto quick quota
>> 262 auto quick quota
>> 263 rw auto quick
>> +264 auto quick
>
> It might be worth to add pool or snaphot groups if you add more
> tests like this.
this can be considered when appropriate I think, as of now there is
one test case in each of them.
Thanks
Anand
next prev parent reply other threads:[~2011-10-20 15:32 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-05 7:59 [PATCH] snapshot, defragment and raid test cases for btrfs Anand Jain
2011-08-05 13:53 ` Amir Goldstein
2011-08-05 15:40 ` Greg Freemyer
2011-08-05 21:42 ` Greg Freemyer
2011-08-06 14:06 ` Dave Chinner
2011-08-11 19:52 ` Anand Jain
2011-08-11 20:01 ` [PATCH 1/3] Added test case 257 for btrfs extended snapshot tests Anand Jain
2011-08-15 7:52 ` [PATCH v2 " Anand Jain
2011-09-02 8:45 ` [PATCH " Christoph Hellwig
2011-08-11 20:01 ` [PATCH 2/3] Added test case 258 for btrfs defragmentation Anand Jain
2011-08-11 20:01 ` [PATCH 3/3] Added test case 259 for the btrfs raid features Anand Jain
2011-09-02 8:49 ` Christoph Hellwig
2011-10-03 11:25 ` Anand Jain
2011-10-10 9:58 ` [PATCH] Changes to received review comments Anand Jain
2011-10-10 11:21 ` Christoph Hellwig
2011-10-11 11:25 ` Anand Jain
2011-10-11 11:26 ` [PATCH 1/3] 263: Functional test case for the btrfs snapshot Anand Jain
2011-10-11 11:38 ` David Sterba
2011-10-11 11:42 ` Christoph Hellwig
2011-10-11 11:47 ` David Sterba
2011-10-11 11:27 ` [PATCH 2/3] 264: Functional test case for the btrfs de-fragmentation Anand Jain
2011-10-11 11:28 ` [PATCH 3/3] 265: Functional test case for the btrfs raid operations Anand Jain
2011-10-12 4:52 ` [PATCH 0/3] xfstest patch Anand Jain
2011-10-12 4:52 ` [PATCH 1/3] 263: Functional test case for the btrfs snapshot Anand Jain
2011-10-13 0:56 ` Dave Chinner
2011-10-18 6:28 ` [PATCH 0/3] xfstests patches Anand Jain
2011-10-18 6:28 ` [PATCH 1/3] 264: Functional test case for the btrfs snapshot Anand Jain
2011-10-19 9:42 ` Christoph Hellwig
2011-10-20 15:31 ` Anand Jain [this message]
2011-10-18 6:28 ` [PATCH 2/3] 265: Functional test case for the btrfs de-fragmentation Anand Jain
2011-10-19 9:43 ` Christoph Hellwig
2011-10-20 15:32 ` Anand Jain
2011-10-18 6:28 ` [PATCH 3/3] 266: Functional test case for the btrfs raid operations Anand Jain
2011-10-19 9:45 ` Christoph Hellwig
2011-10-20 15:32 ` Anand Jain
2011-10-20 15:41 ` [PATCH 0/5] xfstests enhancement and bug fix Anand Jain
2011-10-20 15:41 ` [PATCH 1/5] fill files with random data Anand Jain
2011-10-25 11:35 ` Christoph Hellwig
2011-10-20 15:41 ` [PATCH 2/5] Added SCRATCH_DEV_POOL to specify multiple disks for the btrfs RAID Anand Jain
2011-10-25 11:36 ` Christoph Hellwig
2011-10-20 15:41 ` [PATCH 3/5] 264: Functional test case for the btrfs snapshot Anand Jain
2011-10-25 11:36 ` Christoph Hellwig
2011-10-20 15:41 ` [PATCH 4/5] 265: Functional test case for the btrfs raid operations Anand Jain
2011-10-25 11:37 ` Christoph Hellwig
2011-10-20 15:41 ` [PATCH 5/5] _populate_fs should use OPTIND when getopts is used Anand Jain
2011-10-25 11:37 ` Christoph Hellwig
2011-10-12 4:52 ` [PATCH 2/3] 264: Functional test case for the btrfs de-fragmentation Anand Jain
2011-10-12 4:52 ` [PATCH 3/3] 265: Functional test case for the btrfs raid operations Anand Jain
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4EA03EEB.3020403@oracle.com \
--to=anand.jain@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).