I'm running iozone (http://www.iozone.org/) to benchmark OpenAFS.
Using "iozone -Rac" on a local disk finishes in under an hour. But
with OpenAFS, it ran for about 3 1/2 hour and then kernel paniced. The
panic.log looks like:
------------------------------
panic(cpu 0): zalloc
Latest stack backtrace for cpu 0:
Backtrace:
0x000856CC 0x00085AFC 0x000287A8 0x00042610 0x0002D588
0x001DE940 0x001FEEE8 0x001FBD48
0x16077694 0x16078998 0x16078D00 0x1608B650 0x1608D1D8
0x0020E8CC 0x00092830 0x0042000A
Kernel loadable modules in backtrace (with dependencies):
org.openafs.filesystems.afs(1.2.8)@0x16020000
Proceeding back via exception chain:
Exception state (sv=0x129C0000)
PC=0x9000514C; MSR=0x0000D030; DAR=0x000250B0; DSISR=0x40000000;
LR=0x000058EC; R1=0xBFFFC800; XCP=0x00000030 (0xC00 - System call)
Kernel version:
Darwin Kernel Version 6.3:
Sat Dec 14 03:11:25 PST 2002; root:xnu/xnu-344.23.obj~4/RELEASE_PPC
------------------------------
I ran it a second time, with the same results.
I'm using OpenAFS 1.2.8 with the latest osi_vnodeops.c to fix the
reading beyond EOF problem, plus various patches on the server side.
Stepping through the backtrace, it seems to be in rx_knet.c, where
osi_NetReceive() calls soreceive(), but that's about as far as I know
about.
The output from iozone:
random
random bkwd record stride
KB reclen write rewrite read reread read
write read rewrite read fwrite frewrite fread freread
...
65536 4096 7469 111 124 119 1963
40811
seems to stop between the "random write" and "bkwd read" test, assuming
it is flushing its output appropriately.
Performance, as noted by others, leaves much to be desired, but it
shouldn't cause a panic.
Any ideas?
------------------------------------------------------------------------
--
Edward Moy
Apple Computer, Inc.
[EMAIL PROTECTED]
(This message is from me as a reader of this list, and not a statement
from Apple.)
_______________________________________________
OpenAFS-devel mailing list
[EMAIL PROTECTED]
https://lists.openafs.org/mailman/listinfo/openafs-devel
