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
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
