[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 ;-)
Responsible Changed From-To: freebsd-bugs->julian over to julian
State Changed From-To: open->closed 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.