Date: Mon, 12 Feb 2018 21:08:57 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Andriy Gapon <avg@freebsd.org> Cc: Peter Jeremy <peter@rulingia.com>, "E.S. Rosenberg" <esr@cs.huji.ac.il>, freebsd-fs@freebsd.org Subject: Re: raw filesystem counters Message-ID: <20180212202830.I1446@besplex.bde.org> In-Reply-To: <7e201ce9-6162-ae5e-ea54-6f98cf2dd29f@FreeBSD.org> References: <CA%2BK1OzSda42zBCfT4n0_DScf74TsJyHsxBHaxZwcjkOe3ccmwA@mail.gmail.com> <20180212055505.GD3353@server.rulingia.com> <7e201ce9-6162-ae5e-ea54-6f98cf2dd29f@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Feb 2018, Andriy Gapon wrote: > On 12/02/2018 07:55, Peter Jeremy wrote: >> On 2018-Feb-11 21:06:12 +0200, "E.S. Rosenberg" <esr@cs.huji.ac.il> wrote: >>> Is there any way to access raw disk counters similar to those found on >>> Linux in: >>> /sys/class/block/<device>/stat >>> >>> Preferably also by accessing such a virtual file and not by using iostat / >>> zpool iostat which are already pre-processing counters and need to be run >>> constantly to get accurate real-time estimates. >> >> For the raw disk data, have a look at the statistics functions in >> libgeom(3). You can use the source code for gstat(8) to get a better idea >> how to drive it. geom is too hard to use (try using sysctl kern.geom.con* without a utility to parse it), and doesn't keep its own statistics anyway. gstat(8) actually uses devstat(3) to do most of the work. > Or maybe devstat(3). devstat(3 is about the only usuable method. It never uses geom (except geom in the kernel calls devstat(9) to record things for devstat(3). systat(1) and vmstat(1) use devstat(3) and never use geom. As an example of geom being too hard to use, gstat(8) doesn't work on freefall. It fails in geom_stats_open() and exits with the encrypted error message "No such file or directory". This might be a permissions problem. systat(1) and vmstat(1) have no problems finding a useful list of devices using non-geom methods (mainly devstat_getdevs(3)). >> I don't know of any published API for vdev-level ZFS statistics and, >> unfortunately, "zpool iostat" only supports "humanized" output, which makes >> it difficult to use them as input to further monitoring. There are some >> ARC statistics under sysctl kstat.zfs.misc zfs is also missing support for the per-file-system sync and async write and read statistics that are printed by mount -v if available. The mount -v statistics do a bit more than count these 4 things separately. devstat only has device-level granularity so it can't split or combine or stack devices like geom can. mount -v statistics give splitting at the file system level. "humanized" output is parsable in theory (even by humans) provided it has suffixes to give the units. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180212202830.I1446>