A broken processor usually results in random crashes, not
silent data corruption.
result in both in my practice. with broken companion chips (chipset) it's
silent data corruption is common, while crashes can be under specific
cases. that's from what i've got.
> or even calculate checksum right of wrong data generated by badly
> operating programs.
What do you mean, wrong data generated by programs? If
wrong data generated by program because of hardware problem.
You usually notice it when it's too late and the last
good backup media was already recycled.
not that bad, but of course - i make backups.
> i think all your cases wasn't disk, but general hardware problems.
In my case it was a disk with media surface errors, and
the disk failed to report the error properly to the OS.
Instead it just returned bad data.
so i am just happy to never having it, while normal disk failures are
> ZFS may help detect it, or it may not. if it helped for you.
Please stop spreading FUD. There is no "may or may not".
If a disk returns bad data, ZFS _will_ detect it.
please read more carefully. i didn't say it.
i just say that "disk returning bad data" is very rare case, lots of
other - more frequent - hardware problems will not be detected.
if you like to give lots of CPU power and disk bandwidth for calculation
of checksums on each read/write - then OK.
if you think you are secured this way - then OK.
i just say it doesn't make lot of protection against bad hardware, not
worth the expense.
i probably shouldn't type that point as it can be turned off in ZFS.
email@example.com mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"