Re: Defrag for //gs

[shack@onyx.southwind.net (Randy Shackelford)]

Rubywand (rubywand@swbell.net) wrote:

:      Okay; you are mainly concerned with defragging a hard disk.
: However, a number of tests indicate that, for 800k diskettes, the best
: way to defragment files is via file copy under the standard Finder--
: i.e. you just copy all of the files to /RAM5 or another blank diskette
: and, then, if you used /RAM5, Disk Copy the copy back to diskette. In
: terms of speed gain, the results are much better than for diskettes
: defragged under ProSel. I've never tried using Beach Comber 32.

I don't know where you get that idea. Beach Comber relocates all subdirectories
into contiguous chunks at the beginning of a volume when optimizing. This
alone speeds up file access since the device doesn't have to chase directory
blocks all over the volume. It also places index blocks in chunks to speed
them up. File copying can do neither of these.

:      One interesting result of the tests with 800k diskettes is that the
: file copy defragmented diskettes ended up with some small fragmentation;
: yet, in terms of boot up and file access speed, they wiped out the "no
: fragmented files" diskettes produced via ProSel. Basically, GS/OS +
: ProDOS 'knows best' how to arrange files it is going to access.

GS/OS doesn't have any more choice in placing directory blocks than does 
any other OS using ProDOS. It does look for contiguous empty space for files
instead of blindly allocating the lowest numbered free block each time but
that only helps so much.

:      The above seems to imply that, if there is a place to put hard disk
: files, the best way to defrag a hard disk partition may be to copy the
: files under the Finder to, say, an empty Zip Disk partition. Once the HD
: partition is erased, the files could be file-copied back.

That's absolutely not so with hard disk volumes with lots of directories.
--
Offsite mail to this host gets nuked.