Re: 5-STABLE softupdates issue?

Dan Nelson wrote:
> In the last episode (Nov 24), Scott Long said:
> 
>>Matthias Andree wrote:
>>
>>>out of fun and to investigate claims about alleged bgfsck resource
>>>hogging (which I could not reproduce) posted to
>>>news:de.comp.os.unix.bsd, I pressed the reset button on a live
>>>FreeBSD 5-STABLE system.
>>>
>>>Upon reboot, fsck -p complained about an unexpected softupdates
>>>inconsistency on the / file system and put me into single user
>>>mode, the manual fsck / then asked me to agree to increasing a link
>>>count from 21 to 22 (and later to fix the summary, which I consider
>>>a non-issue). A subsequent fsck -p / ended with no abnormality
>>>detected.
>>
>>No, this in theory should not happen.  YOu could have caught it right
>>at the instance that it was sending a transaction out to disk, or you
>>could have caught an edge case that isn't understood yet. 
>>Unfortunately, ATA drives also cannot be trusted to flush their
>>caches when one would expect, so this leaves open a lot of possible
>>causes for your problem.
> 
> 
> If you just want to test stability in the face of system crashes (and
> not power failure), you can drop to DDB and run "reboot" to simulate a
> panic (or run reboot -qn as root).  That way your drive doesn't lose
> power.
> 
> That said, I get unexpected softupdates inconsistencies pretty
> regularly on kernel panics.  I just let the system run until I can
> reboot and run a fsck -p.
> 

I wonder if this points to dependencies not being pushed out of the
buffer/cache correctly.  That said, I rarely, if ever, see softupdate
problems on my SCSI development systems, but that might just be
coincidence.

Scott