HP3000-L Archives

July 1997, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Stan Sieler <[log in to unmask]>
Reply To:
Stan Sieler <[log in to unmask]>
Date:
Mon, 14 Jul 1997 11:49:01 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (39 lines)
Gilles writes:
>
> You did great right up to the part where you replaced the faulty drive.
>
> What you should have done BEFORE that point was to take a partial backup
> back to the last full - then replace the drive and follow with an install,
> followed by restoration of all files from backup.
>
> You cannot simply replace an existing volume in the system volume set
> without later performing an install. MPEX has nothing to do with your
> problem. And the response center should have told you that.

Actually, you can do surprisingly well for a time ... as long as no
files are on the volume any more (including no file labels!), MPE will
work very well.  In short, he could have replaced the drive, initialized
the new drive as a new volume, and run for a long time with no problems.
I wouldn't recommend doing that, but if you were in a situation where you
couldn't afford a reload, I'd understand your motives.

Where he was "done in" was in the failure to move all files off ldev 15.

BTW, depending upon the number of bad sectors, and whether or not any
happened to affect directories or the label table (or other non-user data),
Steve might have been able to do a disk-to-disk copy (bad disk to good disk)
and boot up with the new drive (which now looks like the same volume as
the old drive), and then restore the (previously known) bad files from
a backup tape (because their disk contents would be partially unknown
after the disk-to-disk copy)...thus avoiding any reload, and avoiding
any question about deleting/adding volumes!

<plug> De-Frag/X's "DisplayExtents" command goes out of its way to
report the ldev a file label is on, if it's different from the
first extent of disk, precisely to help detect this kind of problem.
</plug>

--
Stan Sieler                                          [log in to unmask]
                                     http://www.allegro.com/sieler.html

ATOM RSS1 RSS2