From owner-freebsd-hackers Mon Jun 22 11:01:33 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA15915 for freebsd-hackers-outgoing; Mon, 22 Jun 1998 11:01:33 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id LAA15865 for ; Mon, 22 Jun 1998 11:01:16 -0700 (PDT) (envelope-from tlambert@usr06.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id LAA05897; Mon, 22 Jun 1998 11:01:08 -0700 (MST) Received: from usr06.primenet.com(206.165.6.206) via SMTP by smtp02.primenet.com, id smtpd005839; Mon Jun 22 11:01:02 1998 Received: (from tlambert@localhost) by usr06.primenet.com (8.8.5/8.8.5) id LAA12894; Mon, 22 Jun 1998 11:00:59 -0700 (MST) From: Terry Lambert Message-Id: <199806221800.LAA12894@usr06.primenet.com> Subject: Re: state inode (top) problem To: daniel.sundin@engelholm.se (Daniel Sundin) Date: Mon, 22 Jun 1998 18:00:59 +0000 (GMT) Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <2.2.32.19980620011743.00862a58@pop.engelholm.se> from "Daniel Sundin" at Jun 20, 98 03:17:43 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > What happens when it pauses for 5-6 seconds, according to top, is that it > goes into an 'inode' state. During that time the CPU usage and SIZE usage > decreases alot, but RES stays normal. You are hung waiting for the inode to be inserted into the inode hash list. Most likely, you are suffering a priority inversion on the combination of the simple_lock on the ufs_ihash_slock, and the i_lock on the inode. You could find out if this is the case by placing a printf() before the lockmgr() call in ufs_ihashins(), and another one after the simple_unlock() call in the same function. If there is a delay showing the lock/unlock on the console, then that could be it. Typically, this would happen if a single inode were attempted to be placed onto the hashlist twice; this should never happen. What this might mean is that an inode is being reused before it is freed. Note that I didn't see anywhere where the lock was released. Depending on the implementation, this could be a problem. I would *expect* to see the release in ufs_ihashrem(), for parity's sake. Given the way this is being used, the lock implementation is less opaque than I'd like. > I'd appricate it alot if someone could either tell me what this > might be caused of, and/or what the STATE inode in top means exactly. > The man pages for -current hasnt been updated to describe the new > states. Neither have the block comments in ufs_ihash.c and ffs_vfsops.c. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message