From hsu@clinet.fi Wed Mar 22 06:39:57 1995 Received: from clinet.fi (root@clinet.fi [193.64.6.1]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id GAA05966 for ; Wed, 22 Mar 1995 06:38:18 -0800 Received: from katiska.clinet.fi (root@katiska.clinet.fi [193.64.6.3]) by clinet.fi (8.6.10/8.6.4) with ESMTP id QAA08339 for ; Wed, 22 Mar 1995 16:36:17 +0200 Received: (hsu@localhost) by katiska.clinet.fi (8.6.10/8.6.4) id QAA06482; Wed, 22 Mar 1995 16:36:15 +0200 Message-Id: <199503221436.QAA06482@katiska.clinet.fi> Date: Wed, 22 Mar 1995 16:36:15 +0200 From: Heikki Suonsivu Reply-To: hsu@clinet.fi To: FreeBSD-gnats-submit@freebsd.org Subject: nfs_fsync: dirty: type VREG, usecount 3, writecount 1, refcount 18, X-Send-Pr-Version: 3.2 >Number: 267 >Category: kern >Synopsis: NFS code gives error messages, systems jams for a few seconds >Confidential: no >Severity: serious >Priority: medium >Responsible: davidg >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 22 06:40:00 1995 >Closed-Date: Sat Nov 9 21:19:00 PST 1996 >Last-Modified: Sat Nov 9 21:19:35 PST 1996 >Originator: Heikki Suonsivu >Release: FreeBSD 2.1.0-Development i386 >Organization: Helsinki University of Technology, Finland >Environment: Current (around 20.3.1995). P60, BT PCI controller (new), 32M. There are several NFS mounts in the system, from 2 Sun 3/60's and one from a FreeBSD 1.1.5.1 machine. It tries to act as an nntp server in addition to general use. >Description: We keep getting these. The system seems to stop for a while during each message. Mar 22 16:26:40 katiska /kernel: nfs_fsync: dirty: type VREG, usecount 3, writecount 1, refcount 147, Mar 22 16:26:40 katiska /kernel: tag VT_NFS, fileid 12466 fsid 0x1408 Mar 22 16:26:42 katiska /kernel: nfs_fsync: dirty: type VREG, usecount 3, writecount 1, refcount 7, Mar 22 16:26:42 katiska /kernel: tag VT_NFS, fileid 12466 fsid 0x1408 ... Mar 22 16:32:44 katiska /kernel: tag VT_NFS, fileid 12466 fsid 0x1408 Mar 22 16:32:46 katiska /kernel: nfs_fsync: dirty: type VREG, usecount 3, writecount 1, refcount 10, Mar 22 16:32:46 katiska /kernel: tag VT_NFS, fileid 12466 fsid 0x1408 Mar 22 16:32:48 katiska /kernel: nfs_fsync: dirty: type VREG, usecount 3, writecount 1, refcount 12, Mar 22 16:32:48 katiska /kernel: tag VT_NFS, fileid 12466 fsid 0x1408 Mar 22 16:32:49 katiska /kernel: nfs_fsync: dirty: type VREG, usecount 3, writecount 1, refcount 7, Mar 22 16:32:50 katiska /kernel: tag VT_NFS, fileid 12466 fsid 0x1408 Mar 22 16:32:51 katiska /kernel: nfs_fsync: dirty: type VREG, usecount 3, writecount 1, refcount 13, Mar 22 16:32:51 katiska /kernel: tag VT_NFS, fileid 12466 fsid 0x1408 Mar 22 16:32:54 katiska /kernel: nfs_fsync: dirty: type VREG, usecount 3, writecount 1, refcount 18, Mar 22 16:32:54 katiska /kernel: tag VT_NFS, fileid 12466 fsid 0x1408 Mar 22 16:33:02 katiska /kernel: nfs_fsync: dirty: type VREG, usecount 3, writecount 1, refcount 5, Mar 22 16:33:02 katiska /kernel: tag VT_NFS, fileid 12466 fsid 0x1408 Mar 22 16:33:04 katiska /kernel: nfs_fsync: dirty: type VREG, usecount 3, writecount 1, refcount 16, Mar 22 16:33:04 katiska /kernel: tag VT_NFS, fileid 12466 fsid 0x1408 >How-To-Repeat: I don't know; this appeared in current about a month a ago, but I didn't pay much attention into it as they were infrequent. However it seems that these are getting frequent with high load (news transfers cause a lot of IO). >Fix: Unknown. >Release-Note: >Audit-Trail: State-Changed-From-To: open->closed State-Changed-By: davidg State-Changed-When: Thu Mar 23 01:43:55 PST 1995 State-Changed-Why: This occurred because Heikki has options DIAGNOSTIC in his kernel. The diagnostic message itself is bogus, however, as the condition of having more dirty blocks at that point is both possible and likely since the vnode isn't locked. I've removed the message. State-Changed-From-To: closed->analyzed State-Changed-By: davidg State-Changed-When: Thu Mar 23 01:55:09 PST 1995 State-Changed-Why: On second thought, the vnode does appear to be locked in most or all cases. It appears that the dirty buffers still exist becase the write failed on the server - probably because of a dropped NFS packet. I've changed the state because there isn't enough information to be cetain about the exact cause. I still think the diagnostic message is bogus, however, so it will stay removed in the sources. Responsible-Changed-From-To: freebsd-bugs->davidg Responsible-Changed-By: wollman Responsible-Changed-When: Thu Feb 8 08:51:02 PST 1996 Responsible-Changed-Why: David did the analysis. State-Changed-From-To: analyzed->closed State-Changed-By: scrappy State-Changed-When: Sat Nov 9 21:19:00 PST 1996 State-Changed-Why: Originator Confirmed Closure >Unformatted: