From se@dialup124.zpr.uni-koeln.de  Sun Aug  2 14:32:37 1998
Received: from Octopussy.MI.Uni-Koeln.DE (Octopussy.MI.Uni-Koeln.DE [134.95.166.20])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id OAA21966
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 2 Aug 1998 14:32:36 -0700 (PDT)
          (envelope-from se@dialup124.zpr.uni-koeln.de)
Received: from dialup124.zpr.Uni-Koeln.DE (dialup124.zpr.Uni-Koeln.DE [134.95.219.124])
	by Octopussy.MI.Uni-Koeln.DE (8.8.8/8.8.8) with ESMTP id XAA09779
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 2 Aug 1998 23:32:20 +0200 (MET DST)
Received: (from se@localhost) by dialup124.zpr.Uni-Koeln.DE (8.8.8/8.6.9) id XAA01039; Sun, 2 Aug 1998 23:24:20 +0200 (CEST)
Message-Id: <199808022124.XAA01039@dialup124.zpr.Uni-Koeln.DE>
Date: Sun, 2 Aug 1998 23:24:20 +0200 (CEST)
From: Stefan Esser <se@dialup124.zpr.uni-koeln.de>
Reply-To: se@dialup124.zpr.uni-koeln.de
To: FreeBSD-gnats-submit@freebsd.org
Subject: soft-updates: fsck doesn't fix link count
X-Send-Pr-Version: 3.2

>Number:         7474
>Category:       kern
>Synopsis:       soft-updates: fsck doesn't fix link count
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    julian
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Aug  2 14:40:01 PDT 1998
>Closed-Date:    Mon Nov 16 14:04:21 PST 1998
>Last-Modified:  Mon Nov 16 14:05:29 PST 1998
>Originator:     Stefan Esser
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
>Environment:
3.0-current with CAM + Soft-Updates
>Description:
[The fix to this problem is most probably to be applied to fsck, not 
the kernel, but since this PR is about a file system problem, I consider 
"kern" to be the best category ...]

Since I'm using an experimental NCR driver with CAM patches, I have 
suffered from some instabilities (the system freezes). This is to be 
expected, giving the experimental state of the driver sources, but I
observed several times, that a file that had just been modified or 
moved, ***came out with a link count 1 too high*** after fsck finished
its job.

The last hang occured during a "make install" in the kernel build 
directory, and I cound that the old kernel had already been renamed, 
but the new one had to be re-connected (its directory entry did not
make it to disk in time, but all its blocks had already been written
to safe storage ...)

I deleted the contents of lost+found, but no disk blocks were freed.
A later reboot to single-user and fsck offered to re-connect the 
kernel (and kvm_kernel.db) again (with a link count of 1).

I do not remember the actual circumstances of the first occurence
of this link-count bug, but I had performed two "fsck" in sequence,
and the second one complained about a link count of 2 (should be 1),
even though the previous one seemed to have cleaned up the file system.

>How-To-Repeat:
Interrupt disk operations on a system with soft-updates enabled while a 
file is (e.g.) copied from one file-system to another. Check the results 
of fsck. Look at the link count of the file that has been re-connected
(assuming that there actually was a file to reconnect ;-)
>Fix:
>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->julian 
Responsible-Changed-By: phk 
Responsible-Changed-When: Tue Aug 4 02:23:04 PDT 1998 
Responsible-Changed-Why:  
over to julian 
State-Changed-From-To: open->closed 
State-Changed-By: julian 
State-Changed-When: Mon Nov 16 14:04:21 PST 1998 
State-Changed-Why:  
It is my belief tha t fixes checked in to fsck have resolved this. 
THere is also a new version of FSCK in the wings. 
>Unformatted:
