Pete A <
pete3....@nospam.ntlworld.com> wrote:
> If one stores a HDD in a car then attempts to use it before giving it
> several hours to stabilize to the new environment, it will be operating
> well outside of its design limits (for goodness sake, it was probably
> initially shipped in a cargo hold that went well below its minimum
> storage specifications).
Something like outside -40 to +70°C?
> HDDs are designed to be most reliable when
> continuously powered in an environment of moderate (and slowly
> changing) temperature and humidity.
HDDs don't like shock when operating, condensing and other wetness
and tons of spinup-spindown actions, especially when they have
to use the rotational energy as power source to finish writing
a block and store the heads in a power-out emergency.
> The traditional CRC-16 sector checksum used on most mass storage
> devices is
used nowhere. HDDs of this millennium have several levels of ECC
data, otherwise they wouldn't be able to use such dense magnetic
patterns with any sort of reliability. Same with CDs, even more
so with CDs in data format, same with DVDs, same with BlueRay,
same with Flash memory of any kind, same with magnetic tape.
Even caches in CPUs have ECC. Only main RAM doesn't have ECC
usually (because that would increase the cost by 1/8th). In the
good olden times RAM each 8 byte hat a parity bit (which is more
than enough to make ECC out of them in larger blocks) ...
> a completely useless guarantee of data integrity.
1 out of 2^16 (65,536) is actually pretty good in detecting
data errors if done well.
> If it was
> useful, CRC-16 would be used for integrity instead of MD5 (poor), SHA-1
> (moderate), AES-256 (quite good).
These are used to detect malicious changes by intelligent, whily
opponents, not data corruption (which is random and doesn't try
to hide). Completely different story. Even going in that
direction shows you're merely dropping buzzwords without
understanding what you are saying.
> Even Zip files use the CRC-32 plus a
> recording of the file size to detect data corruption, which is actually
> very robust for reasonably low error-rate systems; unfortunately it has
> no redundancy to recover a corrupted file, but that was not its
> intended purpose - the recipient simply asks the provider to send the
> file again.
Actually, ZIP is a compression format.
All data channels you'd use for transmission of data are very low
error systems (by design, by checksums and resends, by enough
ECC), same as the storage systems you'd use. In practical use
only broken systems would be any other very low error rate systems.
Again you prove you don't see the woods, barking up the
(wrong) tree.
> CD and DVD media were designed to provide reasonably accurate data
> retrieval to inherently fault-tolerant systems, not to provide
> archive-quality mission-critical data integrity. Digital audio and
> video are transmitted via media with an alarmingly high error rate: as
> the error rate increases, the decoding algorithms try to provide
> graceful degradation, which is tailored to human perception rather than
> data integrity.
Again, CD and DVD were designed to be pressed and counter typical
usage damage (scratches etc.), for mass media use. The error
rate isn't alarmingly high: The output is completely correct
for almost everything. You should measure how often your HDD
does error correction, especially when it's a partial response
maximum likelyhood system!
Anyway (you got that partially right) a corrupted sector of 1/75th
second can be faded out without being noticeable in audio CDs.
With video data there's immediately visible artifacts.
> I would suggest to anyone using CDs, DVDs, HDDs, or other mass storage
> devices for backup that they seriously consider using RAR (or an
> equivalent) because it adds redundancy that seems to cope quite well
> with recovery from errors on both mass storage devices and the Internet.
Again a case of too little information and too much buzzwords.
For CDs and DVDs and BlueRays, the correct solution is dvdisaster,
which works more intelligent than PAR, since these media can
fail partially. (2 partially failed media kill your PAR, but
can usually be repaired by dvdisaster.)
For HDDs, partial failure is rare, so PARs saved to the same
HDD are useless. You either live with HDDs being failable and
the chance that both your computer and the backup HDDs failing
simultaneously being a really low chance, or you use RAID (or
similar data spreading) so you can stand losing n (n usually
being 1 or 2) drives out of every set of m backup disks.
> Also make sure you that have a computer with ECC memory and an OS that
> _correctly_ responds to it.
You need a BIOS that does scrubbing. The only OS part that's
"needed" if at all is alerting you to the fact if a certain
memory region begins failing. Actually memtest86+ does a
good job detecting that.
> Without that combination, you may be
> backing-up corrupted data.
It's much more likely that you fail because you never checked your
backup worked. It's much more likely you backed up corrupted data
because your hard drive/controller/cable/... corrupted the data.
> This is one of the common points of failure
> that I referred to in my opening paragraph.
'common' as in 'happens to 100 people in the world per
year'. Many more get murdered. Many more back up corrupted
data due to other reasons than RAM being bad.
99.99% of corrupted data being backed up is because the data
is *already* corrupted on your computer.
> The occasional hardware
> glitch is not as uncommon as we would like to believe.
I've seen it happen. UPS[1], several hard drives[2],
RAM[3][4], several graphics cards[5], ethernet port on
mainboard[6], probably soundcard on mainboard[7],
USB-miniUSB-cable[8], Ethernet cable[9] ...
> Some calibrate
> their monitors quite frequently to ensure colour fidelity, but do these
> same people frequently run exhaustive computer hardware test software?
Why should they? Most such errors are clearly visible:
- a corrupted JPEG caused by some glitch or persistent error is
clearly visibly broken
- a corrupted program crashes
- malfunctioning RAM causes clearly visible reliability problems
(like corrupted JPEG displays and program crashes)
- broken ethernet ports or cables cause no data transferred
- no sound is clearly audible
- freezing HDs or graphics cards etc. cause computer lock ups
and once you get such problems it's time to investigate.
Monitors are *known* to drift away from calibration and near
impossible to catch with the blank eye (even when using comparison
prints), *but* the drift causes, ah, imperfect results which can
be clearly noticable when it's too late and lots of work needs
to be redone.
Clearly, monitors need to be hardware checked. Just like
HDDs are (S.M.A.R.T.).
> If the reader has a tendency to paranoia, I strongly recommend that you
> never run these very long test programs.
If you suffer from paranoia, get treatment.
-Wolfgang
[1] testing it's worn-out batteries automatically and not being
able to switch back to main power in time to prevent a
computer crash.
[2] no data loss, though, though funny things like the firmware
crashing and freezing the computer (as it waited infinitely
for necessary pieces of data or code) after several weeks,
later days and finally refusing to start up every time. Yes,
I usually run my computers 24/7/365.25
[3] that was a known production error in a PDA (pre-flash
memory times): the refresh cycles were not frequent enough
or something. I got it repaired out of warranty for free.
[4] a pair of RAM sticks wouldn't run reliably at full bus speed
when both were inserted. Since that was a new computer anyway,
memtest86 (no '+' back then) caught the error reliably.
Replaced them a few times (for free, of course), until the
dealer gave up and I got 2 from the same production run.
Which worked fine for the lifetime of the computer.
[5] For unknown reasons started to overheat, more prominently
when asked to do 3D graphics. Directing additional air
at them helped, replacing them cured the computer lock ups
(partial, i.e. graphic subsystem only and full lockups, btw.)
The last one was this year.
[6] just went and died. Windows machine, i.e. some games only
and rarely running, usually without network. No idea when
it died. I had a USB-Ethernet converter for my XOs which for
now lives on that machine. Running Linux I could download
the Windows driver for that on said machine. (Linux had
everything on board.)
[7] Untested, but sound sometime back failed. Didn't add a
soundcard board to test the theory yet. Since it's for work
and photoediting sound's a low priority ...
[8] the ssh-via-USB connection to my ebook reader (openinkpot)
failed after several seconds, every time. Switching the USB
cable solved the problem. Would never have thought it could
be the USB cable, so it needed a hint to change it ...
[9] Pings were going out, but not coming in. Cable used to work
previously, it was probably experiencing shear forces at some
point which partially broke it.