In message <20040730150039.GA68176_at_dan.emsphone.com>, Dan Nelson writes: >In the last episode (Jul 30), Poul-Henning Kamp said: >> In message <20040730142537.GH9911_at_dan.emsphone.com>, Dan Nelson writes: >> >> Somebody needs to fix vmstat(8), iostat(8) and systat(8) to look at the >> >> stats inside GEOM instead of the driver stats. It's not very hard to >> >> change, it just takes some work. >> > >> >Just as long as we don't lose stats for non-disk devices like pass and >> >sa. It might be easier to just fix acd. >> >> We won't loose stats for non-disk devices. > >gstat doesn't print them, so I wasn't sure if GEOM even knew about them. If >it does, great! OK, the long story: It used to be that the device driver were responsible for doing the device statistics. These were exported to userland with a sysctl. In GEOM we collect statistics at all providers (and optionally consumers). At the same time I taught devstat subsystem to use shared memory rather than sysctl to export the data to userland. (there's a blueprints article about this stuff in a previous Daemonnews). The geom_disk class bridges these two, and therefore collects statitics for both the old "per driver" and for the GEOM way. This is wasteful since it is the same data collected twice. So the situation right now is that for geom disk device-drivers we have both the old per-driver statistics which programs like vmstat/iostat/systat presents and the per provider statistics which gstat presents. ACD on the other hand is a pure GEOM driver, it does not rely on geom_disk and therefore it only exports the GEOM per-provider statistics and does not show up in systat/vmstat/iostat. So what needs to happen: Teach the selection code in libdevstat some sort of syntax for expressing which devstat entries we want to see in such a manner that we can also show the geom provider entries. (Suggested default: Anything with a geom-rank of one plus anything with no geom connection) [This is perfect bikeshed material btw]. Remove the "per-driver" devstats in geom_disk.c Anyone wanting to attack this problem: please do so and keep the geom_at_freebsd.org crowd in the loop. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk_at_FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.Received on Fri Jul 30 2004 - 14:57:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:04 UTC