Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!decwrl!world!bzs
From: bzs@world.std.com (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: Why is restore so slow?
Message-ID: <BZS.91Mar3135546@world.std.com>
Date: 3 Mar 91 19:55:46 GMT
References: <50235@olivea.atc.olivetti.com> <1013@eplunix.UUCP>
Sender: bzs@world.std.com (Barry Shein)
Organization: The World
Lines: 43
In-Reply-To: das@eplunix.UUCP's message of 29 Jan 91 21:26:54 GMT


>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?

This is a value judgement that may or may not be true in other
people's facilities. C'mon, not everyone does exactly what you do
for a living.

>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!

No, not clear. I worked in a place where they used huge scratch files
and at the time scratch space was at a premium (this is in the days of
washing machine drives.) What they did was take turns running to a
point in their computations (which took days) and then yielding to the
next group (say, over the weekend.) This involved backing up and
restoring all the files for each swap.

In theory it was no big deal and the stop/start had already been honed
down to a simple procedure in the code (given a signal it would write
out its state and exit.)  The only painful part was slow-moving tapes,
each hour of compute time was precious and the switch-over could take
a couple of hours or more.  Just adding more disks wasn't available in
the short-term since these were fixed grant contracts and, alas, using
a coupla grad students who were already paid for made a fair amount of
sense (besides, to get more money would invariably involve promising
more work, diminishing returns.)

Now, there are other ways to do this and they were used (e.g. "dd"),
but that begs the question.

But I think to just cast off a reasonable question with "no reasonable
person would ever want this" often just belies a limit of one's own
imagination. It's a bad knee-jerk in systems work (particularly
because systems people are usually woefully ignorant and even callous
about what their systems are actually used for, and tend to consider
any feature they're personally not interested in as "unnecessary", I
consider that to be the dark side of the systems religion.)
-- 
        -Barry Shein

Software Tool & Die    | bzs@world.std.com          | uunet!world!bzs
Purveyors to the Trade | Voice: 617-739-0202        | Login: 617-739-WRLD