| Message ID | 1360933541-2894-1-git-send-email-hemanthkumar51@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
hi, 2013/2/15 Hemanth Kumar <hemanthkumar51@gmail.com>: > > Signed-off-by: Hemanth Kumar <hemanthkumar51@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 0000000..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 btrfs quota limit is not precise. It allows a little deviation. So if we limit a subvolume 3M, what we can write must be less than 3M. What's more, for a subvolume, metadata is included in a subvolume quota...(4KB).. What i really want to say is that btrfs quota is a little complex, To test hierarchical quotas feature still needs more things to consider...maybe you should have a deep understanding of it firstly... However, this is a good start i think. ^_^ Thanks, Wang > + > +cleanup > +exit > -- > 1.8.1.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" 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 linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 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 <hemanthkumar51@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 0000000..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. > @@ -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. This text doesn't belong in the script -- it's your commit message, and needs to go above the S-o-B line above. I'd recommend using git for your development, because when you do a commit, it'll give you a place to put the commit message. Then, with git-format-patch and git-send-email (and the dry-run option), you can get it to format the mail exactly right, instead of producing slightly mangled output as here. > +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 What happens if one of these commands fails? You should be testing the exit status of almost every command. 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). 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. 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. > +cleanup > +exit It's the end of the script. You don't need to use exit here. Hugo. (*) OK, you could actually test quite a bit of the userspace tools even on a system with no btrfs module, by using an LD_PRELOAD library that stubs out the btrfs ioctls and records which ioctls have been called. But for now, I'd suggest that you leave that idea alone.
On Fri, Feb 15, 2013 at 08:59:06PM +0000, 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.
On Sat, Feb 16, 2013 at 06:55:09PM +1100, Dave Chinner wrote: > On Fri, Feb 15, 2013 at 08:59:06PM +0000, 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.
On Mon, Feb 18, 2013 at 10:44:06AM +0530, Hemanth Kumar wrote: > On Sat, Feb 16, 2013 at 2:29 AM, Hugo Mills <hugo@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 <hemanthkumar51@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 0000000..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.
diff --git a/hq.sh b/hq.sh new file mode 100644 index 0000000..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
Signed-off-by: Hemanth Kumar <hemanthkumar51@gmail.com> --- hq.sh | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 hq.sh