Get ztest working for OSX port

[GoogleCodeExporter]

ZTest may be useful for stress testing the mounted ZFS drives (suggested by  
jason.richard.mcneil)

http://hub.opensolaris.org/bin/view/Community+Group+zfs/ztest

Original issue reported on code.google.com by alex.ble...@gmail.com on 27 Oct 2009 at 9:27

• Blocked on: Port libumem #37

[GoogleCodeExporter]

Original comment by alex.ble...@gmail.com on 27 Oct 2009 at 9:28

[GoogleCodeExporter]

Getting ztest working looks like it is going to be fun… even the old version 
in b72 of the OpenSolaris code ztest 
will need a work to get it working on the current code. Which of course will 
all change again if we can move to 
b126 in the future.

Until ztest is working I'm using a script[1] of my own to do some sort of 
stress testing. It's not near the level of 
completeness that the ztest would cover, but it at least does some basic 
testing using fstools and bonnie. For 
instance, on both my machines if I startup four instances of the script 
(waiting at least one second between each) 
one of the four will hang soon after while the other three will run for hours 
with no issue. Seems that once one 
zpool triggers whatever bug it is, it doesn't trigger it again.

The script doesn't prove much just yet, but at least you'll know if your debug 
build, like some of mine, have 
broken some basic functions.

[1] http://github.com/jasonrm/mac-zfs/blob/master/test/ramdisk-test.sh

Original comment by jason.richard.mcneil on 29 Oct 2009 at 5:33

[GoogleCodeExporter]

I did look through ZFS and pretty much came to the same consclusion.  I'd say
``tedious'' more than ``fun'', though.  I'm not sure it'd be particularly hard, 
but
it would take a lot of time.

Original comment by dsalli...@gmail.com on 29 Oct 2009 at 4:40

[GoogleCodeExporter]

Although I still am using fstools and bonnie, I've also been playing around 
with postmark [0] for file 
create/read/write/append/delete testing... seems to stress a ZFS filesystem 
quite a bit, but I've yet to make it 
cause a kernel panic so I'm not certain that it's going to be enough of a 
stress test.

I've also tried fstest [1] which, from what I understand from the FreeBSD ZFS 
port paper [2], was written to test 
various aspects of the ZFS implementation. On a test ZFS filesystem with no 
changes to the test cases it failed 17 
out of 1950 subtests. Oddly enough, I can't get it to even complete a run on a 
HFS+ partition, likely because ZFS 
supports more Unix-y things than HFS+. ZFS being about 20 or so years newer 
also helps I'm sure.

There is another fstest [3] that seems to deal just with random file access. 
Might be worth also using to verify 
that the ZFS checksum parts actually are working. My fork of it works on Mac OS 
10.6.2, but I have no idea how 
it does on 10.5 so patches are welcome. ;)

So even if we never get ztest working, I figure we should have some sort of 
test-bench and stress-test scripts. 
And of course, if there are better tools already out there, I'd be glad to use 
something already written too.

[0] http://www.freshports.org/benchmarks/postmark/
[1] http://github.com/jasonrm/fstest-FreeBSD
[2] http://2007.asiabsdcon.org/papers/P16-paper.pdf
[3] http://github.com/jasonrm/fstest

Original comment by jason.richard.mcneil on 16 Jan 2010 at 9:38

[GoogleCodeExporter]

Original comment by alex.ble...@gmail.com on 7 Mar 2010 at 8:40

[GoogleCodeExporter]

Original comment by alex.ble...@gmail.com on 11 Mar 2010 at 7:59

[GoogleCodeExporter]

Ok, just a note that I have started to make ztest working.
Current state: required libzpool is down to < 15 compile errors, ztest itself
compiles.  Code will go github as soon as it compiles clean.

Original comment by googlelogin@bjoern-kahl.de on 14 Mar 2010 at 3:19

• Changed state: Started

[GoogleCodeExporter]

A trial version is available at 
http://github.com/BjoKaSH/mac-zfs/tree/ztest_port

This port is based on albues tag pre_merge_72, so it should match the released 
binary
installer.
BUT: porting ztest revealed a number of missing kcondvar_t initializer in the
released code, this has been fixed in this branch.

Next step: merge into current master.

Original comment by googlelogin@bjoern-kahl.de on 28 Mar 2010 at 7:50

[GoogleCodeExporter]

Forgot to mention:
I wasn't able to find a way around XCodes inability to run dynamically linked
executables with uninstalled shared libs.  So ztest does not work *within* 
xcode,
because it tries to fork and exec zdb, which failed because it can't find its 
libraries.

Run ztest-static instead, it will fork and exec zdb-static and works just fine

Original comment by googlelogin@bjoern-kahl.de on 28 Mar 2010 at 7:57

[GoogleCodeExporter]

Thanks, I'll see if I can give it a go later on today. 

Original comment by alex.ble...@gmail.com on 28 Mar 2010 at 8:40

[GoogleCodeExporter]

Update:

I restarted the work on ztest et.al.  Currently it compiles on maczfs_73, next 
step is to integrate ztest et.al. into current stable maczfs_74_x

Original comment by googlelogin@bjoern-kahl.de on 13 Aug 2012 at 9:04

• Now blocked on: Port libumem #37