On Sun, 12 Sep 2010 16:16:53 -0500 (CDT) Robert Bonomi <bon...@mail.r-bonomi.com> wrote:
> There are exactly _four_ possible causes of file-system > inconsistencies. 1) You can have an unexpected loss of power, where > the CPU stops working before it as time to write the above-mentioned > 'memory-resident' data to disk. There are sub-classes of tis event, > to distinguish between A utility company outage, somebody > accidentally 'pulling the plug', be it litterally, or the power > on/off switch, and somebody itting the 'reset' button. They all ave > te same effect, the processor can't get te 'current' data in memory > out to the disk. 2) you can hve a catastropic O/S failure -- a system > 'crash' -- were the O/S has discovered an internal inconsistency. > _IT_ doesn't trust its own data enough to keep running, and takes > 'the lesser of two evils' route of *not* writing "known to be > suspect" data over the out-of-date data on the disk. > 3) 'bit rot' on the phyiscal media itself. Where what gets read > back is *not* what was written there earlier. Modern disk drives > detect this inside the controller and use embedded ECC info to give > the 'right' data back, while alerting that the problem exists. > 4) "Hardware failures" of any of a variety of sorts -- flakey power > supply, bad RAM memory, failing controller cipes, etc. 5. An bug in the filesystem code. I've been seeing UFS corruption in recently -current, as have others, which isn't associated with crashes or bad media. -- Bruce Cran _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
