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 <FreeBSD-gnats-submit@freebsd.org>; 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 <FreeBSD-gnats-submit@freebsd.org>; 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 <hsu@clinet.fi>
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:




