Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!ncrlnk!emdeng!hrich
From: hrich@emdeng.Dayton.NCR.COM (George.H.Harry.Rich)
Newsgroups: comp.arch
Subject: Re: Workstation Data Integrity
Message-ID: <1080@emdeng.Dayton.NCR.COM>
Date: 29 Aug 90 12:17:48 GMT
References: <6797.26d6edce@vax1.tcd.ie> <56qmo1w162w@zl2tnm.gp.govt.nz>
Reply-To: hrich@emdeng.UUCP (George.H.Harry.Rich)
Organization: NCR, E&M Dayton
Lines: 34

rwallace@vax1.tcd.ie writes:

> hard disk goodbye. Let's see, when did I do my last full backup?). So the PC
> parity protection is worse than useless.

I've had three hard disks trashed by hardware problems.  Every one of them
went, not because systems  failed to update the directory and allocation map, 
but because they updated the directory and allocation map from trashed memory 
and the trashing was undetected.  Lest I create paranoia, two of the systems 
were prototypes, and one was an ancient, abused, non-standard, and  flaky 
PDP-11/05.

Given a properly organized disk caching system, loss of data already on
disk due to system halts is a very low probability occurance.  If it
happens often, you should get a different caching system.  (Sales pitch
deleted).

My own experience is that a parity error on a good workstation is a once in a
blue moon occurance. (Sales pitch deleted).  In my environment, where I'm doing
a lot of changing and testing, stopages due to software bugs or incompatabilies
are much more frequent.

My suggestion is that you don't commit more than
half an hour's work to ram or more than a day's work to hard disk.  A day's
contingency in a software schedule will take care of this.  If you don't
have a day's contingency, you should be making selective backups more
often; you can do them during think time if you organize them properly.

Regards,

	Harry Rich

Disclaimer:  The ideas expressed here are mine and not necessarily those
of my employer.