From owner-freebsd-current Sat Jun 28 16:44:52 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id QAA08815 for current-outgoing; Sat, 28 Jun 1997 16:44:52 -0700 (PDT) Received: from implode.root.com (implode.root.com [198.145.90.17]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA08810 for ; Sat, 28 Jun 1997 16:44:50 -0700 (PDT) Received: from implode.root.com (localhost [127.0.0.1]) by implode.root.com (8.8.5/8.8.5) with ESMTP id QAA02926; Sat, 28 Jun 1997 16:45:37 -0700 (PDT) Message-Id: <199706282345.QAA02926@implode.root.com> To: ade@demon.net cc: freebsd-current@freebsd.org Subject: Re: 3.0-current issues (build 97-06-28) In-reply-to: Your message of "Sat, 28 Jun 1997 23:47:35 BST." From: David Greenman Reply-To: dg@root.com Date: Sat, 28 Jun 1997 16:45:37 -0700 Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >And now, for another query. > >With the current -current, pstat -T falls over as follows: > > aleste 101# pstat -T > 179/4136 files > pstat: sysctl: KERN_VNODE: No such file or directory > >with a little bit of tracking down, this would appear to be because >of the following code in sys/kern/vfs_subr.c, line 1858: > >---------------------------------------------------------------------- >/* > * XXX > * Exporting the vnode list on large systems causes them to crash. > * Exporting the vnode list on medium systems causes sysctl to coredump. > */ >#if 0 >SYSCTL_PROC(_kern, KERN_VNODE, vnode, CTLTYPE_OPAQUE|CTLFLAG_RD, > 0, 0, sysctl_vnode, "S,vnode", ""); >#endif >---------------------------------------------------------------------- > >This isn't really a big problem for me, since I only use pstat -T >as a way of tracking swap file usage, and I can use swapinfo instead, Huh? That should be "pstat -s" to look at swap usage. >but I'm a little confused as to why something that *seemed* to work >flawlessy in 2.2.2-RELEASE has been commented out in 3.0-CURRENT. I was the one who commented it out. It caused sysctl on systems the size of yours to coredump, and caused systems larger than yours to panic. The vnode table on wcarchive, for instance, is 45000 entries large and the mechanism that is used to copy all of the many megabytes of kernel data structures out to the user process simply can't handle things this large. There are also security concerns when exporting detailed information about open files. -DG David Greenman Core-team/Principal Architect, The FreeBSD Project