Subject: Re: vmstat and netstat....
To: Manuel Bouyer <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 03/27/2006 07:56:17
Manuel Bouyer wrote:
> On Sun, Mar 26, 2006 at 11:16:37PM -0800, Garrett D'Amore wrote:
>> It was recently pointed out that a few commands (vmstat, netstat)
>> require a kernel file (/netbsd) in the root filesystem in order to
>> provide, for example, accurate statistics.
> Are you sure ? Can you give examples ? AFAIK these commands uses
> sysctl to get the statistics on live systems, /netbsd (or the kernel
> binary specified by -N) is used only when working on crashdumps.
That's true on FreeBSD, but not of the code in NetBSD. I'd be happy
with that as a solution for NetBSD.
> I don't have a /netbsd on my Xen domUs, and didn't notice missing
> functionalities with netstat/vmstat
Try vmstat -e.
>> There was also the point recently about how some userland tools could be
>> made more "port-independent" if they didn't grovel around in memory.
>> (E.g. the fact that some tools may be sensitive to a different size for
>> paddr_t used on different MIPS ports.)
>> The need for a /netbsd kernel is particularly onerous for some platforms
>> where disk space is at a premium.
>> I'm wondering whether there is a compelling reason why we shouldn't
>> convert new versions of the tools to read these values out of kernfs
>> special files. This would provide increased portability and remove the
>> reliance on having a /netbsd that matches the loaded kernel.
> The way to do this on a live system is to use sysctl to collect the
> informations. If netstat or vmstat still requires to read kernel memory
> to get some info, it's probably better to add the sysctl nodes to retrieve
> them than to add kernfs nodes.
Sysctl is a prefectly good idea.
>> The only drawback I can think of is that some of these tools operate on
>> crash dumps, and a kernfs reader wouldn't be able to do that. If that
>> functionality is important, could it be provided by gdb scripts or
>> similar? And would folks find that an acceptable solution, or is the
>> ability for these tools to operate on crashdumps themselves an immutable
>> requirement? Am I missing something else?
> This is a very important functionality, and I think it should be keept in
> these tools (no need to make it harder for sysadmins), but the
> kernel binary is only needed to do post-mortem analysis (or at last,
And, after examination, this is what FreeBSD does. OpenBSD and NetBSD
use the kernel binary and /dev/kmem.
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191