Re: Testing BTRFS
On 03/10/2014 06:02 PM, Avi Miller wrote: Oracle Linux 6 with the Unbreakable Enterprise Kernel Release 2 or Release 3 has production-ready btrfs support. You can even convert your existing CentOS6 boxes across to Oracle Linux 6 in-place without reinstalling: http://linux.oracle.com/switch/centos/ Oracle also now provides all errata, including security and bug fixes for free athttp://public-yum.oracle.com and our kernel source code can be found athttps://oss.oracle.com/git/ Is there any issue with BTRFS and 32 bit O/S like with ZFS? -Ben -- 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
Re: Testing BTRFS
Hi, On 14 Mar 2014, at 5:10 am, Lists li...@benjamindsmith.com wrote: Is there any issue with BTRFS and 32 bit O/S like with ZFS? We provide some btrfs support with the 32-bit UEK Release 2 on OL6, but we strongly recommend only using the UEK Release 3 which is 64-bit only. -- Oracle http://www.oracle.com Avi Miller | Product Management Director | +61 (3) 8616 3496 Oracle Linux and Virtualization 417 St Kilda Road, Melbourne, Victoria 3004 Australia -- 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
xfstests btrfs/035 (was Re: Testing BTRFS)
Hi Eric, On Tue, 11 Mar 2014 14:08:02 -0500, Eric Sandeen wrote: Indeed, testing 3.8.13-26.2.1.el6uek.x86_64 (which is, I believe, the kernel which Avi referred to) via xfstests, I saw failures on btrfs/009 and btrfs/022; then the box deadlocked on btrfs/024. I rebooted resumed, then deadlocked on btrfs/030. Rebooted and resumed again, then panicked on btrfs/035. At that point I stopped. FWIW, Liu Bo recently proposed a fix for the btrfs/035 BUG_ON(): http://permalink.gmane.org/gmane.comp.file-systems.btrfs/33327 Cheers, David -- 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
Re: Testing BTRFS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/10/2014 08:39 PM, Lists wrote: I'd like to begin testing BTRFS. We'd probably begin roll out in 6 months to a year if testing goes well. We're currently using CentOS6/64 everywhere, are aware of BTRFS being a Technology preview in RHEL 7beta and would like to begin testing production-level load testing. We generate about 10 GB of distinct data daily that is stored redundantly by default on a combination of ZFS and Ext4. Is there a recommended way to do this? Is it anywhere as easy as ZFSonLinux yum install? There is way too much churn for any enterprise distro to be able to keep up with bugfixes and stuff. You are best off rolling your own kernel based on the stable series if you want to think about using btrfs in production. Thanks, Josef -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTHxCtAAoJEANb+wAKly3BdJ8QAK5hYoNtJT/UEkpKakpNoXfV q6lg2NVPT6EeHzcMhTRS+VTOJ/bjvfwX0qDxRkjvo73F+nkQYcrO78cEMvPqtwTq HKxrGMibCtt5PlzzcbKqSc1VGIDFEkD2z7fr5y2n4V+E5x0EPCFxU6VOjXgqXyEZ 8tKW24oxLAwbWBvyiaKrB/gWm47Aw6p2pVWgWrqMjMFUaNQBoisAU+1Ezn0Xjg6w 4wazfGqUkUZ3pMcZr5IMQ9X+p+FUid7JWcdNwPjIsPMQhP7mkIK0Mq8eDu6ijVv2 nI52pZuYaZs3+7OlkEoHRssnAwIWUwUq9UQwRjl4WK8FrpgdyYe0n2zlZIWGinvF qZRMmB5PtM+SYT9Wt5OPAgZxb/ivc9Vz7ACG4edNSBqZ1D7+52aazT4JY0fqWGGU 8vapdKUmyXPQT9MphvHUEqnJtA/K9ek8Frt+f304KCcl/0IEESAoo3InlS7Hw45D ANEO4ZCwaUp/WjhqvwuvhYrqn8ENsbCm31RYAvAGEOoROzwXEnbl/Nv4DaKa+Q7b I6uSpyS60cNA2wmKm3wzFGpvSkP8PMzA1zSepK/yJ9p3PxUdxUpY1OqYc8y7gqOf +ACNUuNMbNwAhMb9udEZzuBZojX3/vVPlqOWLPYDr3fVCrDIwuSKtloao+czkrpo sxJbe80q3rqtw+p0pStO =n1mD -END PGP SIGNATURE- -- 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
Re: Testing BTRFS
On 3/10/14, 8:02 PM, Avi Miller wrote: On 11 Mar 2014, at 11:39 am, Lists li...@benjamindsmith.com wrote: Is there a recommended way to do this? Is it anywhere as easy as ZFSonLinux yum install? Oracle Linux 6 with the Unbreakable Enterprise Kernel Release 2 or Release 3 has production-ready btrfs support. You can even convert your existing CentOS6 boxes across to Oracle Linux 6 in-place without reinstalling: http://linux.oracle.com/switch/centos/ If we're plugging distros... I can also tell you that you can install upcoming RHEL7 on btrfs if you like, and it has a very up-to-date btrfs codebase. Of course Fedora and other non-enterprise distros have btrfs support as well. But we're keeping it tech preview in RHEL7 for now, because in our testing, it does not yet reach the level of reliability that we wish to provide to our customers. Indeed, testing 3.8.13-26.2.1.el6uek.x86_64 (which is, I believe, the kernel which Avi referred to) via xfstests, I saw failures on btrfs/009 and btrfs/022; then the box deadlocked on btrfs/024. I rebooted resumed, then deadlocked on btrfs/030. Rebooted and resumed again, then panicked on btrfs/035. At that point I stopped. Ben, the best advice I have for you is to test *your* workload on btrfs with whatever qualification tests you have, and see how things fare. If you want to know the current state of btrfs, test the upstream code as best you can; if you hope to deploy on a distribution with a longer support window, test on that distribution. But I agree with Josef that for now, the fixes and changes are still flying fast furious, and except in limited use cases, btrfs is not yet ready for general commercial deployment. -Eric -- 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
Re: Testing BTRFS
Hey, On 12 Mar 2014, at 6:08 am, Eric Sandeen sand...@redhat.com wrote: If we're plugging distros... I can also tell you that you can install upcoming RHEL7 on btrfs if you like, and it has a very up-to-date btrfs codebase. Ditto for OL7, for obvious reasons. :) Indeed, testing 3.8.13-26.2.1.el6uek.x86_64 (which is, I believe, the kernel which Avi referred to) via xfstests, I saw failures on btrfs/009 and btrfs/022; then the box deadlocked on btrfs/024. I rebooted resumed, then deadlocked on btrfs/030. Rebooted and resumed again, then panicked on btrfs/035. At that point I stopped. We have a bunch of btrfs fixes queued for UEK3-QU2 which is in alpha build internally at the moment. We do run the full xfstests against our UEK3 releases and are working with Liu Bo to backport fixes from mainline which should resolve some (hopefully all) of the failing xfstests. It’s also worth ensuring that you’re upgrading the userspace btrfs-progs package that ships with the updated UEK3 kernels, if applicable. Ben, the best advice I have for you is to test *your* workload on btrfs with whatever qualification tests you have, and see how things fare. If you want to know the current state of btrfs, test the upstream code as best you can; if you hope to deploy on a distribution with a longer support window, test on that distribution. Agreed. But I agree with Josef that for now, the fixes and changes are still flying fast furious, and except in limited use cases, btrfs is not yet ready for general commercial deployment. Obviously, we disagree (somewhat) here. We’re happy with the status of btrfs functionality in UEK3 to provide limited production support, but this is just from the Oracle Linux team. The other product teams within Oracle (RDBMS, Java, middleware, etc) obviously have to do their own validation and testing and are responsible for their own support. As above, I agree with Eric that you should test your own workloads and requirements and make your own judgement call. Cheers, Avi -- Oracle http://www.oracle.com Avi Miller | Product Management Director | +61 (3) 8616 3496 Oracle Linux and Virtualization 417 St Kilda Road, Melbourne, Victoria 3004 Australia -- 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
Testing BTRFS
I'd like to begin testing BTRFS. We'd probably begin roll out in 6 months to a year if testing goes well. We're currently using CentOS6/64 everywhere, are aware of BTRFS being a Technology preview in RHEL 7beta and would like to begin testing production-level load testing. We generate about 10 GB of distinct data daily that is stored redundantly by default on a combination of ZFS and Ext4. Is there a recommended way to do this? Is it anywhere as easy as ZFSonLinux yum install? -Ben -- 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
Re: Testing BTRFS
On 11 Mar 2014, at 11:39 am, Lists li...@benjamindsmith.com wrote: Is there a recommended way to do this? Is it anywhere as easy as ZFSonLinux yum install? Oracle Linux 6 with the Unbreakable Enterprise Kernel Release 2 or Release 3 has production-ready btrfs support. You can even convert your existing CentOS6 boxes across to Oracle Linux 6 in-place without reinstalling: http://linux.oracle.com/switch/centos/ Oracle also now provides all errata, including security and bug fixes for free at http://public-yum.oracle.com and our kernel source code can be found at https://oss.oracle.com/git/ Cheers, Avi -- Oracle http://www.oracle.com Avi Miller | Product Management Director | +61 (3) 8616 3496 Oracle Linux and Virtualization 417 St Kilda Road, Melbourne, Victoria 3004 Australia -- 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
Re: [btrfs-progs] testing btrfs hierarchical quotas
On Mon, Feb 18, 2013 at 10:44:06AM +0530, Hemanth Kumar wrote: On Sat, Feb 16, 2013 at 2:29 AM, Hugo Mills h...@carfax.org.uk wrote: Here's a question -- what are you testing? (Not just here, but in general, with your test infrastructure) There are (at least) three classes of tests you could be doing: 1) Unit tests, which test individual functions within the code and ensure they do what they're meant to do. 2) Integration tests, which test the full end-to-end system. 3) Partial integration tests, which exercise the kernel filesystem code. 4) Partial integration tests, which exercise the userspace tools code. Now, clearly you're not doing (1) here. It's going to be hard to separate (2) from (3) and (4), but it's possible to write your tests to do more of one or of the other. (*) I am tying to write a script to test quota subsystem (qgroups) and hierarchical quota as suggested by Arne Jansen. Since i am trying to write a script to test a particular feature i guess it falls under unit testing category No, unit testing would typically be testing one individual function in the code, independently of the rest of the code-base. e.g. a battery of very small simple tests which verify that the device_size() function in utils.c returns the correct value in all cases. When you say test a particular feature, you haven't distinguished between testing the *kernel* feature (i.e. does the kernel behave correctly?) and the *userspace* feature (i.e. does the userspace tool make all of the checks that it should do, tell the kernel to do the right thing, and return useful information when something fails?). It's hard to separate these two fully without effectively reimplementing some part of the other side, but the decision either way will make a difference as to the set of tests you end up implementing. xfstests clearly is much more geared to (3), and stresses the kernel filesystem implementation rather than the userspace tools. If you want to test the implementation of qgroups, it belongs in xfstests. If you want to test the userspace code, you need to make sure that (over all your tests) you cover every command-line option, and every different way of using the tool, and ensure that it does the right things. What you've written in this patch seems to be more about testing the kernel behaviour than the userspace tools, but it'd be good if you can put your work into the context I've just talked about above. More comments below... On Fri, Feb 15, 2013 at 06:35:41PM +0530, Hemanth Kumar wrote: Signed-off-by: Hemanth Kumar hemanthkuma...@gmail.com --- hq.sh | 33 + 1 file changed, 33 insertions(+) create mode 100644 hq.sh diff --git a/hq.sh b/hq.sh new file mode 100644 index 000..6a0a820 --- /dev/null +++ b/hq.sh Rather cryptic filename here. If this is to be applied to btrfs-progs, I'd recommend putting all your test scripts in a test subdir, and a test target in the Makefile that invokes the tests. Can you elaborate on this part a bit more. Ignore my comment. As Dave Chinner pointed out, this is best integrated into xfstests. [snip] You may want to take a look at my earlier work on this, at: http://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg13153.html That should at least give you a basic infrastructure to work in. [snip] Thank you, I will take a look at your script and continue my work. Again, don't bother -- Dave was right, and my assumptions about what xfstests was actually doing were wrong. Use xfstests instead. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- We believe in free will because we have no choice. --- signature.asc Description: Digital signature
Re: [btrfs-progs] testing btrfs hierarchical quotas
On Sat, Feb 16, 2013 at 06:55:09PM +1100, Dave Chinner wrote: On Fri, Feb 15, 2013 at 08:59:06PM +, Hugo Mills wrote: Hi, Hemanth, Here's a question -- what are you testing? (Not just here, but in general, with your test infrastructure) There are (at least) three classes of tests you could be doing: 1) Unit tests, which test individual functions within the code and ensure they do what they're meant to do. 2) Integration tests, which test the full end-to-end system. 3) Partial integration tests, which exercise the kernel filesystem code. 4) Partial integration tests, which exercise the userspace tools code. Now, clearly you're not doing (1) here. It's going to be hard to separate (2) from (3) and (4), but it's possible to write your tests to do more of one or of the other. (*) xfstests clearly is much more geared to (3), and stresses the kernel filesystem implementation rather than the userspace tools. If Definitely not. There are lots of userspace tools tests in xfstests for stuff like mkfs.xfs, xfs_repair, xfs_dump/restore, xfs_quota, xfs_metadump/restore, xfs_copy, etc. OK, this is my mistake. I guess I've basically seen so many kernel-side things fail from xfstests, I'd assumed that was exclusively what it was testing. Thanks for the correction. you want to test the implementation of qgroups, it belongs in xfstests. If you want to test the userspace code, you need to make sure that (over all your tests) you cover every command-line option, and every different way of using the tool, and ensure that it does the right things. Yup, that's why there are are so many xfs specific tests. :) e.g. there are 31 tests that use xfsdump/restore in lots of different ways, including exercising dumping to tape devices if you have the hardware... [snip] Seriously, guys, just write new tests for xfstests. Everything you need to run btrfs-progs tests is already there. Don't try to re-invent the wheel simply because you don't understand how the current wheels we have are made As long as xfstests already has tests for userspace tools in it, then I'm quite happy to see it all go there. My point about being clear exactly which bit of the end-to-end system the test is there to exercise still stands, though. Hugo. -- === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk === PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk --- He's playing Schubert. I think Schubert is losing. --- signature.asc Description: Digital signature
[btrfs-progs] testing btrfs hierarchical quotas
Signed-off-by: Hemanth Kumar hemanthkuma...@gmail.com
---
hq.sh | 33 +
1 file changed, 33 insertions(+)
create mode 100644 hq.sh
diff --git a/hq.sh b/hq.sh
new file mode 100644
index 000..6a0a820
--- /dev/null
+++ b/hq.sh
@@ -0,0 +1,33 @@
+#! /bin/bash
+# Btrfs quotas test case
+# Hi all,
+# This is shell script to test the hierarchical quotas feature of Btrfs
+# I created Btrfs filesystem on a new
+# partition, then activated quota management ('btrfs quota enable'), and
+# created a few subvolumes of multiple levels.
+
+
+cleanup()
+{
+btrfs subvolume delete $TEST_DIR/vol1/vol2/vol3
+btrfs subvolume delete $TEST_DIR/vol1/vol2
+btrfs subvolume delete $TEST_DIR/vol1
+btrfs subvolume disable $TEST_DIR
+}
+
+#trap _cleanup ; exit \$status 0 1 2 3 15
+
+btrfs quota enable $TEST_DIR
+echo quota enabled on $TEST_DEV
+btrfs subvolume create $TEST_DIR/vol1
+btrfs subvolume create $TEST_DIR/vol1/vol2
+btrfs subvolume create $TEST_DIR/vol1/vol2/vol3
+btrfs qgroup limit 5m $TEST_DIR/vol1
+btrfs qgroup limit 3m $TEST_DIR/vol1/vol2
+btrfs qgroup limit 2m $TEST_DIR/vol1/vol2/vol3
+dd if=$TEST_DEV of=$TEST_DIR/vol1/vol2/vol3/file1 bs=3M count=1
+dd if=$TEST_DEV of=$TEST_DIR/vol1/vol2/file1 bs=2M count=1
+dd if=$TEST_DEV of=$TEST_DIR/vol1/file1 bs=5M count=1
+
+cleanup
+exit
--
1.8.1.2
--
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
Re: [btrfs-progs] testing btrfs hierarchical quotas
On Fri, Feb 15, 2013 at 08:59:06PM +, Hugo Mills wrote:
Hi, Hemanth,
Here's a question -- what are you testing? (Not just here, but in
general, with your test infrastructure)
There are (at least) three classes of tests you could be doing:
1) Unit tests, which test individual functions within the code and
ensure they do what they're meant to do.
2) Integration tests, which test the full end-to-end system.
3) Partial integration tests, which exercise the kernel
filesystem code.
4) Partial integration tests, which exercise the userspace tools code.
Now, clearly you're not doing (1) here. It's going to be hard to
separate (2) from (3) and (4), but it's possible to write your tests
to do more of one or of the other. (*)
xfstests clearly is much more geared to (3), and stresses the
kernel filesystem implementation rather than the userspace tools. If
Definitely not. There are lots of userspace tools tests in xfstests
for stuff like mkfs.xfs, xfs_repair, xfs_dump/restore,
xfs_quota, xfs_metadump/restore, xfs_copy, etc.
you want to test the implementation of qgroups, it belongs in
xfstests. If you want to test the userspace code, you need to make
sure that (over all your tests) you cover every command-line option,
and every different way of using the tool, and ensure that it does the
right things.
Yup, that's why there are are so many xfs specific tests. :) e.g.
there are 31 tests that use xfsdump/restore in lots of different
ways, including exercising dumping to tape devices if you have the
hardware...
Another small comment that needs to be pointed out:
+cleanup()
+{
+btrfs subvolume delete $TEST_DIR/vol1/vol2/vol3
+btrfs subvolume delete $TEST_DIR/vol1/vol2
+btrfs subvolume delete $TEST_DIR/vol1
+btrfs subvolume disable $TEST_DIR
+}
+
+#trap _cleanup ; exit \$status 0 1 2 3 15
This test is clearly derived from an xfstests test script (status,
the trap, the cleanup function, the tmp variable, use of TEST_DEV
and TEST_DIR, etc), but it clearly isn't a functional test without
the rest of the xfstests harness...
+btrfs quota enable $TEST_DIR
+echo quota enabled on $TEST_DEV
+btrfs subvolume create $TEST_DIR/vol1
+btrfs subvolume create $TEST_DIR/vol1/vol2
+btrfs subvolume create $TEST_DIR/vol1/vol2/vol3
+btrfs qgroup limit 5m $TEST_DIR/vol1
+btrfs qgroup limit 3m $TEST_DIR/vol1/vol2
+btrfs qgroup limit 2m $TEST_DIR/vol1/vol2/vol3
+dd if=$TEST_DEV of=$TEST_DIR/vol1/vol2/vol3/file1 bs=3M count=1
+dd if=$TEST_DEV of=$TEST_DIR/vol1/vol2/file1 bs=2M count=1
+dd if=$TEST_DEV of=$TEST_DIR/vol1/file1 bs=5M count=1
What happens if one of these commands fails?
The xfstests harness would catch the error message because it
wouldn't match the golden output.
You should be testing
the exit status of almost every command.
No need with xfstests. As I said, the golden output image matching
will catch the error message emitted by the failed comand...
Then you can fail in one of
two different ways: a failure of the test (where the thing you were
trying to test has not succeeded), or a failure of the test harness
(where the setup functions have gone wrong).
But both can be detected the same way without having to put anything
in the test script to detect it.
I'd do this with a setup function to set up the test environment, a
teardown function to undo it cleanly afterwards, and one or more test
functions which can be used to run tests.
Which is already provided by xfstests.
+cleanup
+exit
It's the end of the script. You don't need to use exit here.
Copied again from a xfstests test, obviously without understanding
what the commented out trap does.
$ man bash
.
exit [n]
Cause the shell to exit with a status of n. If n is
omitted, the exit status is that of the last command
executed. A trap on EXIT is executed before the
shell terminates.
.
trap [-lp] [[arg] sigspec ...]
.
If a sigspec is EXIT (0) the command arg is executed
on exit from the shell.
IOWs, the trap command causes the cleanup function to be called
automatically on exit
Seriously, guys, just write new tests for xfstests. Everything you
need to run btrfs-progs tests is already there. Don't try to
re-invent the wheel simply because you don't understand how the
current wheels we have are made
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
--
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
[PATCH] Xfstests/254: add more cases for testing btrfs snapshot in 254
From: Zhou Bo zhoub-f...@cn.fujitsu.com
This patch adds more cases in 254 for testing btrfs snapshot.
Signed-off-by: Zhou Bo zhoub-f...@cn.fujitsu.com
---
254 | 321 ++-
1 files changed, 317 insertions(+), 4 deletions(-)
diff --git a/254 b/254
index 7b74a02..9c320d0 100755
--- a/254
+++ b/254
@@ -23,13 +23,14 @@
#
# creator
owner=jo...@redhat.com
-
+owner=zhoub-f...@cn.fujitsu.com
+n=0
seq=`basename $0`
echo QA output created by $seq
here=`pwd`
tmp=/tmp/$$
-status=1 # failure is the default!
+status=0 # success is the default!
_cleanup()
{
@@ -47,7 +48,7 @@ _supported_fs btrfs
_supported_os Linux
_require_scratch
-_scratch_mkfs /dev/null 21
+_scratch_mkfs_sized `expr 1024 \* 1024 \* 1024` /dev/null 21
_scratch_mount
# First test basic snapshotting
@@ -105,4 +106,316 @@ _scratch_remount
echo List root dir
ls $SCRATCH_MNT
-status=0 ; exit
+# The following is added in 2012/07/12, add more cases for testing snapshot
+
+_prepare_snapshot()
+{
+ _scratch_remount /dev/null
+ btrfs sub snap $SCRATCH_MNT $SCRATCH_MNT/basesnapshot /dev/null
2$here/$seq.full
+ btrfs sub snap -r $SCRATCH_MNT $SCRATCH_MNT/readonlysnapshot
/dev/null 2$here/$seq.full
+ _scratch_unmount /dev/null 2$here/$seq.full
+ VALID_SUBVOLUME=basesnapshot
+ VALID_RO_SUBVOLUME=readonlysnapshot
+ SNAPSHOTSTR=snapshot
+ FILE1=file1-
+ FILE2=file2-
+ MVFILE2=newfile2-
+ DIR1=dir1-
+ DIR2=dir2-
+ MVDIR2=newdir2-
+ MVSNAPSHOT=mvsnapshot-
+ SRCSUBVOL=srcsubvol-
+}
+
+_parse_options()
+{
+ SOURCE_TARGET=$1
+ case $SOURCE_TARGET in
+ 1)
+ SOURCE_SUBVOLUME=$VALID_SUBVOLUME
+ ;;
+ esac
+ SOURCE_READ=$2
+ case $SOURCE_READ in
+ 1)
+ SOURCE_SUBVOLUME=$VALID_RO_SUBVOLUME
+ ;;
+ esac
+ DESTINATION_TARGET=$3
+ case $DESTINATION_TARGET in
+ 1)
+ DESTINATION_SUBVOLUME=$SNAPSHOTSTR$n
+ ;;
+ esac
+ DESTINATION_READ=$4
+ case $DESTINATION_READ in
+ 1)
+ SNAPSHOTOPT_STR=-r
+ ;;
+ 2)
+ SNAPSHOTOPT_STR=
+ ;;
+ esac
+ MOUNT_OPT=$5
+ case $MOUNT_OPT in
+ 1)
+ MOUNT_OPT_STR=
+ ;;
+ 2)
+ MOUNT_OPT_STR=-r
+ ;;
+ 3)
+ MOUNT_OPT_STR=-o nodatacow
+ ;;
+ esac
+ FILE_OPERATION_OPT=$6
+ SNAPSHOT_ACTION_OPT=$7
+ TEST_DIR1=$DIR1$n
+ TEST_DIR2=$DIR2$n
+ TEST_MVDIR2=$MVDIR2$n
+ TEST_FILE1=$FILE1$n
+ TEST_FILE2=$FILE2$n
+ TEST_MVFILE2=$MVFILE2$n
+ TEST_MVSNAPSHOT=$MVSNAPSHOT$n
+ SRC_SUBVOLUME=$SRCSUBVOL$n
+ n=$[n+1]
+}
+
+_create_file()
+{
+ mkdir $SRC_SUBVOLUME/$TEST_DIR1 $SRC_SUBVOLUME/$TEST_DIR2 /dev/null
+ touch $SRC_SUBVOLUME/$TEST_FILE1 $SRC_SUBVOLUME/$TEST_FILE2 /dev/null
+}
+
+_do_file_operation()
+{
+ btrfs filesystem balance $SCRATCH_MNT /dev/null 21
+ rm -rf $SRC_SUBVOLUME/$TEST_DIR1 $SRC_SUBVOLUME/$TEST_FILE1 /dev/null
+ mv $SRC_SUBVOLUME/$TEST_DIR2 $SRC_SUBVOLUME/$TEST_MVDIR2 /dev/null
+ mv $SRC_SUBVOLUME/$TEST_FILE2 $SRC_SUBVOLUME/$TEST_MVFILE2 /dev/null
+}
+
+_do_snapshot_action()
+{
+ if [ $SNAPSHOT_ACTION_OPT == 2 ];then
+ btrfs subvolume delete $DESTINATION_SUBVOLUME /dev/null
2$here/$seq.full
+ fi
+ if [ $SNAPSHOT_ACTION_OPT == 3 ];then
+ mv $DESTINATION_SUBVOLUME $TEST_MVSNAPSHOT /dev/null
2$here/$seq.full
+ fi
+}
+
+_check_snapshot()
+{
+ if [ $SNAPSHOT_ACTION_OPT == 2 ];then
+ if [ -d $DESTINATION_SUBVOLUME ];then
+ echo case $n fails, deleting snapshot fails.
$here/$seq.full
+ status=1
+ fi
+ fi
+ if [ $SNAPSHOT_ACTION_OPT == 3 ];then
+ if [ ! -d $TEST_MVSNAPSHOT ];then
+ echo case $n fails, renaming snapshot fails.
$here/$seq.full
+ status=1
+ fi
+ fi
+
+}
+
+_check_file()
+{
+ cd $DESTINATION_SUBVOLUME
+ if [ $FILE_OPERATION_OPT == 2 ];then
+ if [ -d $TEST_DIR1 ];then
+ echo case $n fails, before snapshot we delete dir in
src, but it exists in snap $here/$seq.full
+ status=1
+ fi
+ if [ -f $TEST_FILE1 ];then
+ echo case $n fails, before snapshot we delete file in
src, but it exists in snap $here/$seq.full
+ status=1
+ fi
[PATCH] Xfstests/254: add more cases for testing btrfs snapshot in 254
From: Zhou Bo zhoub-f...@cn.fujitsu.com
This patch adds more cases in 254 for testing btrfs snapshot.
Signed-off-by: Zhou Bo zhoub-f...@cn.fujitsu.com
---
254 | 321 ++-
1 files changed, 317 insertions(+), 4 deletions(-)
diff --git a/254 b/254
index 7b74a02..9c320d0 100755
--- a/254
+++ b/254
@@ -23,13 +23,14 @@
#
# creator
owner=jo...@redhat.com
-
+owner=zhoub-f...@cn.fujitsu.com
+n=0
seq=`basename $0`
echo QA output created by $seq
here=`pwd`
tmp=/tmp/$$
-status=1 # failure is the default!
+status=0 # success is the default!
_cleanup()
{
@@ -47,7 +48,7 @@ _supported_fs btrfs
_supported_os Linux
_require_scratch
-_scratch_mkfs /dev/null 21
+_scratch_mkfs_sized `expr 1024 \* 1024 \* 1024` /dev/null 21
_scratch_mount
# First test basic snapshotting
@@ -105,4 +106,316 @@ _scratch_remount
echo List root dir
ls $SCRATCH_MNT
-status=0 ; exit
+# The following is added in 2012/07/12, add more cases for testing snapshot
+
+_prepare_snapshot()
+{
+ _scratch_remount /dev/null
+ btrfs sub snap $SCRATCH_MNT $SCRATCH_MNT/basesnapshot /dev/null
2$here/$seq.full
+ btrfs sub snap -r $SCRATCH_MNT $SCRATCH_MNT/readonlysnapshot
/dev/null 2$here/$seq.full
+ _scratch_unmount /dev/null 2$here/$seq.full
+ VALID_SUBVOLUME=basesnapshot
+ VALID_RO_SUBVOLUME=readonlysnapshot
+ SNAPSHOTSTR=snapshot
+ FILE1=file1-
+ FILE2=file2-
+ MVFILE2=newfile2-
+ DIR1=dir1-
+ DIR2=dir2-
+ MVDIR2=newdir2-
+ MVSNAPSHOT=mvsnapshot-
+ SRCSUBVOL=srcsubvol-
+}
+
+_parse_options()
+{
+ SOURCE_TARGET=$1
+ case $SOURCE_TARGET in
+ 1)
+ SOURCE_SUBVOLUME=$VALID_SUBVOLUME
+ ;;
+ esac
+ SOURCE_READ=$2
+ case $SOURCE_READ in
+ 1)
+ SOURCE_SUBVOLUME=$VALID_RO_SUBVOLUME
+ ;;
+ esac
+ DESTINATION_TARGET=$3
+ case $DESTINATION_TARGET in
+ 1)
+ DESTINATION_SUBVOLUME=$SNAPSHOTSTR$n
+ ;;
+ esac
+ DESTINATION_READ=$4
+ case $DESTINATION_READ in
+ 1)
+ SNAPSHOTOPT_STR=-r
+ ;;
+ 2)
+ SNAPSHOTOPT_STR=
+ ;;
+ esac
+ MOUNT_OPT=$5
+ case $MOUNT_OPT in
+ 1)
+ MOUNT_OPT_STR=
+ ;;
+ 2)
+ MOUNT_OPT_STR=-r
+ ;;
+ 3)
+ MOUNT_OPT_STR=-o nodatacow
+ ;;
+ esac
+ FILE_OPERATION_OPT=$6
+ SNAPSHOT_ACTION_OPT=$7
+ TEST_DIR1=$DIR1$n
+ TEST_DIR2=$DIR2$n
+ TEST_MVDIR2=$MVDIR2$n
+ TEST_FILE1=$FILE1$n
+ TEST_FILE2=$FILE2$n
+ TEST_MVFILE2=$MVFILE2$n
+ TEST_MVSNAPSHOT=$MVSNAPSHOT$n
+ SRC_SUBVOLUME=$SRCSUBVOL$n
+ n=$[n+1]
+}
+
+_create_file()
+{
+ mkdir $SRC_SUBVOLUME/$TEST_DIR1 $SRC_SUBVOLUME/$TEST_DIR2 /dev/null
+ touch $SRC_SUBVOLUME/$TEST_FILE1 $SRC_SUBVOLUME/$TEST_FILE2 /dev/null
+}
+
+_do_file_operation()
+{
+ btrfs filesystem balance $SCRATCH_MNT /dev/null 21
+ rm -rf $SRC_SUBVOLUME/$TEST_DIR1 $SRC_SUBVOLUME/$TEST_FILE1 /dev/null
+ mv $SRC_SUBVOLUME/$TEST_DIR2 $SRC_SUBVOLUME/$TEST_MVDIR2 /dev/null
+ mv $SRC_SUBVOLUME/$TEST_FILE2 $SRC_SUBVOLUME/$TEST_MVFILE2 /dev/null
+}
+
+_do_snapshot_action()
+{
+ if [ $SNAPSHOT_ACTION_OPT == 2 ];then
+ btrfs subvolume delete $DESTINATION_SUBVOLUME /dev/null
2$here/$seq.full
+ fi
+ if [ $SNAPSHOT_ACTION_OPT == 3 ];then
+ mv $DESTINATION_SUBVOLUME $TEST_MVSNAPSHOT /dev/null
2$here/$seq.full
+ fi
+}
+
+_check_snapshot()
+{
+ if [ $SNAPSHOT_ACTION_OPT == 2 ];then
+ if [ -d $DESTINATION_SUBVOLUME ];then
+ echo case $n fails, deleting snapshot fails.
$here/$seq.full
+ status=1
+ fi
+ fi
+ if [ $SNAPSHOT_ACTION_OPT == 3 ];then
+ if [ ! -d $TEST_MVSNAPSHOT ];then
+ echo case $n fails, renaming snapshot fails.
$here/$seq.full
+ status=1
+ fi
+ fi
+
+}
+
+_check_file()
+{
+ cd $DESTINATION_SUBVOLUME
+ if [ $FILE_OPERATION_OPT == 2 ];then
+ if [ -d $TEST_DIR1 ];then
+ echo case $n fails, before snapshot we delete dir in
src, but it exists in snap $here/$seq.full
+ status=1
+ fi
+ if [ -f $TEST_FILE1 ];then
+ echo case $n fails, before snapshot we delete file in
src, but it exists in snap $here/$seq.full
+ status=1
+ fi
Re: [PATCH] Xfstests/254: add more cases for testing btrfs snapshot in 254
Please ignore this...I forgot to CC xfs, sorry.
thanks,
liubo
On 07/19/2012 05:24 PM, Liu Bo wrote:
From: Zhou Bo zhoub-f...@cn.fujitsu.com
This patch adds more cases in 254 for testing btrfs snapshot.
Signed-off-by: Zhou Bo zhoub-f...@cn.fujitsu.com
---
254 | 321
++-
1 files changed, 317 insertions(+), 4 deletions(-)
diff --git a/254 b/254
index 7b74a02..9c320d0 100755
--- a/254
+++ b/254
@@ -23,13 +23,14 @@
#
# creator
owner=jo...@redhat.com
-
+owner=zhoub-f...@cn.fujitsu.com
+n=0
seq=`basename $0`
echo QA output created by $seq
here=`pwd`
tmp=/tmp/$$
-status=1 # failure is the default!
+status=0 # success is the default!
_cleanup()
{
@@ -47,7 +48,7 @@ _supported_fs btrfs
_supported_os Linux
_require_scratch
-_scratch_mkfs /dev/null 21
+_scratch_mkfs_sized `expr 1024 \* 1024 \* 1024` /dev/null 21
_scratch_mount
# First test basic snapshotting
@@ -105,4 +106,316 @@ _scratch_remount
echo List root dir
ls $SCRATCH_MNT
-status=0 ; exit
+# The following is added in 2012/07/12, add more cases for testing snapshot
+
+_prepare_snapshot()
+{
+ _scratch_remount /dev/null
+ btrfs sub snap $SCRATCH_MNT $SCRATCH_MNT/basesnapshot /dev/null
2$here/$seq.full
+ btrfs sub snap -r $SCRATCH_MNT $SCRATCH_MNT/readonlysnapshot
/dev/null 2$here/$seq.full
+ _scratch_unmount /dev/null 2$here/$seq.full
+ VALID_SUBVOLUME=basesnapshot
+ VALID_RO_SUBVOLUME=readonlysnapshot
+ SNAPSHOTSTR=snapshot
+ FILE1=file1-
+ FILE2=file2-
+ MVFILE2=newfile2-
+ DIR1=dir1-
+ DIR2=dir2-
+ MVDIR2=newdir2-
+ MVSNAPSHOT=mvsnapshot-
+ SRCSUBVOL=srcsubvol-
+}
+
+_parse_options()
+{
+ SOURCE_TARGET=$1
+ case $SOURCE_TARGET in
+ 1)
+ SOURCE_SUBVOLUME=$VALID_SUBVOLUME
+ ;;
+ esac
+ SOURCE_READ=$2
+ case $SOURCE_READ in
+ 1)
+ SOURCE_SUBVOLUME=$VALID_RO_SUBVOLUME
+ ;;
+ esac
+ DESTINATION_TARGET=$3
+ case $DESTINATION_TARGET in
+ 1)
+ DESTINATION_SUBVOLUME=$SNAPSHOTSTR$n
+ ;;
+ esac
+ DESTINATION_READ=$4
+ case $DESTINATION_READ in
+ 1)
+ SNAPSHOTOPT_STR=-r
+ ;;
+ 2)
+ SNAPSHOTOPT_STR=
+ ;;
+ esac
+ MOUNT_OPT=$5
+ case $MOUNT_OPT in
+ 1)
+ MOUNT_OPT_STR=
+ ;;
+ 2)
+ MOUNT_OPT_STR=-r
+ ;;
+ 3)
+ MOUNT_OPT_STR=-o nodatacow
+ ;;
+ esac
+ FILE_OPERATION_OPT=$6
+ SNAPSHOT_ACTION_OPT=$7
+ TEST_DIR1=$DIR1$n
+ TEST_DIR2=$DIR2$n
+ TEST_MVDIR2=$MVDIR2$n
+ TEST_FILE1=$FILE1$n
+ TEST_FILE2=$FILE2$n
+ TEST_MVFILE2=$MVFILE2$n
+ TEST_MVSNAPSHOT=$MVSNAPSHOT$n
+ SRC_SUBVOLUME=$SRCSUBVOL$n
+ n=$[n+1]
+}
+
+_create_file()
+{
+ mkdir $SRC_SUBVOLUME/$TEST_DIR1 $SRC_SUBVOLUME/$TEST_DIR2 /dev/null
+ touch $SRC_SUBVOLUME/$TEST_FILE1 $SRC_SUBVOLUME/$TEST_FILE2 /dev/null
+}
+
+_do_file_operation()
+{
+ btrfs filesystem balance $SCRATCH_MNT /dev/null 21
+ rm -rf $SRC_SUBVOLUME/$TEST_DIR1 $SRC_SUBVOLUME/$TEST_FILE1 /dev/null
+ mv $SRC_SUBVOLUME/$TEST_DIR2 $SRC_SUBVOLUME/$TEST_MVDIR2 /dev/null
+ mv $SRC_SUBVOLUME/$TEST_FILE2 $SRC_SUBVOLUME/$TEST_MVFILE2 /dev/null
+}
+
+_do_snapshot_action()
+{
+ if [ $SNAPSHOT_ACTION_OPT == 2 ];then
+ btrfs subvolume delete $DESTINATION_SUBVOLUME /dev/null
2$here/$seq.full
+ fi
+ if [ $SNAPSHOT_ACTION_OPT == 3 ];then
+ mv $DESTINATION_SUBVOLUME $TEST_MVSNAPSHOT /dev/null
2$here/$seq.full
+ fi
+}
+
+_check_snapshot()
+{
+ if [ $SNAPSHOT_ACTION_OPT == 2 ];then
+ if [ -d $DESTINATION_SUBVOLUME ];then
+ echo case $n fails, deleting snapshot fails.
$here/$seq.full
+ status=1
+ fi
+ fi
+ if [ $SNAPSHOT_ACTION_OPT == 3 ];then
+ if [ ! -d $TEST_MVSNAPSHOT ];then
+ echo case $n fails, renaming snapshot fails.
$here/$seq.full
+ status=1
+ fi
+ fi
+
+}
+
+_check_file()
+{
+ cd $DESTINATION_SUBVOLUME
+ if [ $FILE_OPERATION_OPT == 2 ];then
+ if [ -d $TEST_DIR1 ];then
+ echo case $n fails, before snapshot we delete dir in
src, but it exists in snap $here/$seq.full
+ status=1
+ fi
+ if [ -f $TEST_FILE1 ];then
+ echo case $n fails, before snapshot we delete file in
src, but it exists
Re: [PATCH] Xfstests/254: add more cases for testing btrfs snapshot in 254
On Thu, Jul 19, 2012 at 06:27:07PM +0800, Liu Bo wrote: From: Zhou Bo zhoub-f...@cn.fujitsu.com This patch adds more cases in 254 for testing btrfs snapshot. Signed-off-by: Zhou Bo zhoub-f...@cn.fujitsu.com I think it is better to create a new test than modify the old one. That way it is easy to tell the difference between a new failure and regression. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- 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
Re: [PATCH] Xfstests/254: add more cases for testing btrfs snapshot in 254
On 07/20/2012 08:24 AM, Dave Chinner wrote: On Thu, Jul 19, 2012 at 06:27:07PM +0800, Liu Bo wrote: From: Zhou Bo zhoub-f...@cn.fujitsu.com This patch adds more cases in 254 for testing btrfs snapshot. Signed-off-by: Zhou Bo zhoub-f...@cn.fujitsu.com I think it is better to create a new test than modify the old one. That way it is easy to tell the difference between a new failure and regression. Sure, that makes sense. thanks, liubo Cheers, Dave. -- 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
