Path: utzoo!attcan!uunet!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.sys.apple2
Subject: Re: Optimizing
Message-ID: <13032@smoke.BRL.MIL>
Date: 31 May 90 19:15:52 GMT
References: <357.apple.info-apple@pro-fishunt>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 53

In article <357.apple.info-apple@pro-fishunt> z@pro-fishunt.cts.com (Jim Ziogas) writes:
>1) I have heard that a periodic re-formatting of a hard drive will improve its
>performance. Well, I use ProSel-16 to optimize hy hard drive often. So, is
>anything else besides optimization achieved by re-formatting? Do I really need
>to re-format the drive?

Assuming you really mean reformatting rather than reinitializing, there
is no reason to do so unless new unusable blocks have turned up since
the last time you formatted it.  Restoring a backup to a freshly
initialized filesystem improves performance simply because the files
are reallocated contiguously; under normal operation (creating and
deleting files) the disk becomes "fragmented", meaning that a single
file may be stored in several noncontiguous sections scattered across
the disk.  Presumably ProSel-16 "optimization" reallocates files
contiguously by moving their pieces around.

>2) I have two equal partitions on my 60 meg drive. The first contains all of
>the GS/OS boot stuff and gs-specific stuff, while the second contains all
>8-bit stuff. Well, about 6 months ago, I ran the ProSel-16 bad block scan and
>lockout. I came across 230+ bad blocks on the second partition. I just got the
>drive a year ago, but it wasn't until 6 months ago that I ran the bad block
>scan. I don't know if these bad blocks were always there or if the appeared
>after some use. No more have popped up, but those 230+ are still there. My
>question is this- are these blocks anything to worry about? Are bad blocks
>normal? It seemed to be a very routine step in ProSel-16, so I don't know what
>to think.

I don't know exactly what ProSel-16 is doing, but indeed large hard
disks usually have some bad blocks (locations that cannot be reliably
used for storage).  Under normal circumstances these are detected
when the low-level formatting is performed, and a "bad block table"
is recorded on the disk, along with corresponding good blocks to be
used as surrogates for the bad ones.  If the GS/OS "verify disk"
operation reports no bad blocks, then all the actually bad blocks are
not used for data storage, in which case they are probably remapped
via the bad block list.  (By the way, most hard disks have a factory-
determined bad block list, to which other bad blocks may be appended
as they are discovered.)  Defects in disk surfaces occasionally spread
to encompass formerly usable blocks, so it is a good idea to scan for
bad blocks from time to time.

>Also, could number 2 be related to number 1 at all?

Only slightly, in that revectored bad blocks require the disk head to
be repositioned onto the spare block track occasionally, which adds
extra seek time over that which would be required if all actual data
blocks were contiguous.  (This is the same phenomenon that makes
fragmentation adversely affect performance.)

>The bad blocks are at the end of the second partion. Could the software be
>reading more than what's there?

Again, run "verify disk" and if it succeeds you're in good shape.