$ zfs-stats -A ... ARC Eviction Statistics: Evicts Total: 1511504896 Evicts Eligible for L2: 83.05% 1255353344 Evicts Ineligible for L2: 16.95% 256151552 Evicts Cached to L2: 0 Illegal option -5 Illegal option -3 Illegal option -7 Illegal option -0 /usr/local/bin/zfs-stats: arithmetic expression: expecting primary: " / * 100 " $ uname -a FreeBSD wklptp 11.0-CURRENTAPRIL2015svn280766 FreeBSD 11.0-CURRENTAPRIL2015svn280766 #0 7ea2786(master): Fri Mar 27 21:15:50 EDT 2015 root@avenger:/usr/obj/root/pcbsd-build-11-CURRENTAPRIL2015/git/freebsd/sys/GENERIC amd64
08:46 < cem> dteske: ping? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199255 08:46 < cem> dteske: anything i can run / grab to help diagnose? 08:57 * dteske reads 08:57 < dteske> cem: yes 08:59 < dteske> cem: if you could run "sh -x `which zfs-stats` -- -A 2>&1 | tee zfs-stats.log" (assuming you're using bash; if using *csh remove 2>&1 and replace | with |& 08:59 < dteske> cem: I suspect is that some of the sysctl's don't exist on that platform 08:59 < dteske> cem: in which case, I'll have a NULL string expanded in the place of an lvalue to arithmetic operand(s) 08:59 < dteske> cem: thus causing the arithmetic expression syntax errors 09:01 < dteske> .oO( with your logged output, it should be a simple matter of assigning suitable defaults either globally or for the MIBs/OIDs that don't exist on pcbsd 11 09:01 < dteske> assuming that this *is* pcbsd 11 )
cem was able to provide me with the requested output. The cause of the issue is: ### TRACE BEGIN 7534 + anon_hits=-9099 ... 7584 + f_perc -9099 / 2219655 anon_hits_perc 7585 + local 'OPTIND=1' OPTARG __flag '__np=' 7586 + getopts n: __flag 7587 Illegal option -9 7588 + getopts n: __flag 7589 Illegal option -0 7590 + getopts n: __flag 7591 Illegal option -9 7592 + getopts n: __flag 7593 Illegal option -9 7594 + getopts n: __flag 7595 + shift 1 7596 + local '__dividend=/' 7597 + shift 1 7598 /usr/local/bin/zfs-stats: arithmetic expression: expecting primary: " / * 100 " ### TRACE END The f_perc() function for calculation percentages uses "getopts" to interpret feature flags. The leading minus-sign on the negative number is causing the numerical value to be treated instead as feature flags. While it's distressing that the following calculation produces a negative number: echo $(( $( sysctl -n kstat.zfs.misc.arcstats.hits) - ( $( sysctl -n kstat.zfs.misc.arcstats.mfu_hits ) + $( sysctl -n kstat.zfs.misc.arcstats.mru_hits ) + $( sysctl -n kstat.zfs.misc.arcstats.mfu_ghost_hits ) + $( sysctl -n kstat.zfs.misc.arcstats.mru_ghost_hits ) ) )) That can (and should) be attributed to the fault of counter handling in zfs.ko. Without doing anything to change the fact that the kernel is producing a negative calculation, I can (and should) update f_perc() to account for negative numbers. While I was here, I also found another discrepancy wherein a code-typo is preventing the display of the "Chain Max" property. I will need to do a search/replace of s/chains_max/chain_max/g.
Working on it
Heading its way into ports: http://druidbsd.sf.net/download/zfs-stats-lite-1.3.tar.gz Online source/revision history: http://druidbsd.cvs.sf.net/viewvc/druidbsd/pkgbase/freebsd/RELENG_8_3_AMD64/sysutils/zfs-stats-lite/src/bin/zfs-stats?view=log
https://reviews.freebsd.org/D3673
A commit references this bug: Author: dteske Date: Mon Nov 2 21:07:23 UTC 2015 New revision: 400672 URL: https://svnweb.freebsd.org/changeset/ports/400672 Log: Bump to 1.3: Fix handling of negative numbers PR: ports/199255 Differential Revision: https://reviews.freebsd.org/D3673 Reviewed by: feld Approved by: feld Changes: head/sysutils/zfs-stats-lite/Makefile head/sysutils/zfs-stats-lite/distinfo
Both version 1.2 and 1.3 (recently committed) together when combined address this port.