Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!tut.cis.ohio-state.edu!ucbvax!ulysses!ulysses.att.com!andys
From: andys@ulysses.att.com (Andy Sherman)
Newsgroups: comp.unix.wizards
Subject: Re: Why is restore so slow?
Message-ID: <14260@ulysses.att.com>
Date: 4 Feb 91 15:42:17 GMT
References: <50235@olivea.atc.olivetti.com> <1013@eplunix.UUCP>
Sender: netnews@ulysses.att.com
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 25

In article <1013@eplunix.UUCP> das@eplunix.UUCP (David Steffens) writes:
>All right, my $0.02 on this issue.
>
>Who cares how slow restore is?  How often do you do have to do
>full restore on a filesystem or a whole disk?  Once or twice a year?
>If it's more often than that, then you have a REAL problem
>and maybe you ought to spend your time and energy fixing THAT!

The frequency of file system restores, even in the best run shops, is
directly proportional to the number of disks spinning.  We have
something like 100 disks in our computer center (*NOT* counting the
things attached to workstations and PCs).  MTBFs are 30000 hours on
about a third of them and 100000 hours on the rest.  Go ahead and do
the math.  We are statistically doomed to an awful lot of disk
failures just based on the volume.  Now not every failure is a
catastrophic failure requiring a full restore of the file system, but
I suspect that more than one or two a year will be.  With users
clamoring for us to get their data back on line, restore performance
is a concern.  Reliability is a more urgent concern, of course, but
you try fighting these folks off.....
--
Andy Sherman/AT&T Bell Laboratories/Murray Hill, NJ
AUDIBLE:  (201) 582-5928
READABLE: andys@ulysses.att.com  or att!ulysses!andys
What? Me speak for AT&T?  You must be joking!