Disk Mirroring - private opinion
Vadim G. Antonov
avg at hq.demos.su
Sun Sep 2 21:29:38 AEST 1990
>
> MTBF(controllers) >> MTBF(disks)
>
I have no idea about this statement but I sure that
MTBF(software) << MTBF(disks)
is true. I used to work on machines failing several times
a day due to hard CPU errors, with disks reporing CRC errors
one time per 100 i/o requests and containing "floating"
bad sectors. Original Unix could not work on my machine
even a quarter of hour (it was really failing!). But I haven't
lost a byte of my information during several years.
So, if you like to keep your data on-line you should
choose a better scheme than mirroring because it't QUITE
USELESS against software (and software-related like an
improper handling of power faults) bugs.
The only way to protect yourself against software failures
is to keep your data IN DIFFERENT FORMATS. I mean
file-by-file dumping etc.
Another important thing to do is to design a REAL error
handling in drivers - for example, a disk driver should
check controller's internals as much as possible. The Unix
drivers is usually designed without keeping such things in
mind.
And last (but not least) thing is a fault-tolerant file system.
Sys V format is NOT fault-tolerant. BSD systems behave a much
fairly. Some things in Unix are REALLY dangerous - like a
writing access time stamp directly into inode. "Unmodifyed
information should be kept unchanged". An experimental fact:
if you'd hack out writing i_atime your system will be 10-20%
more reliable.
NEVER use software w/o source codes - it gives you no chance
to improve reliability of your installation.
> ...I'm not cynical - just experienced.
So, my private opinion is that the mirrored disk is not
the best and VERY expensive vehicle to carry your bits on. :-)
Regards,
Vadim Antonov,
DEMOS, Moscow, USSR
(It is NOT a joke!)
More information about the Comp.unix.sysv386
mailing list