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