bates@spectr.DEC (Ken Bates DTN 522-2039) (10/14/85)
While perusing through the disk file structure, I happened to notice that several files were fragmented; the first part was on one part of the disk and the remainder was 30 or 40 tracks away. Although the idea of discontiguous files is quite nice from a storage allocation standpoint, it also has a tendency to introduce extra times when loading or accessing the files, since the majority of file load time is acuator movement, not data transfer. As an experiment, I wrote a small program which did seeks over the disk in an attempt to discover exactly what the seek times were. The results went from a low of .015 seconds for a single track seek to a high of 1.08 seconds (!) for a 79 track seek, with the seek times being relatively linear, depending only on the track to track distance. No discernable differences were observed due to the different speed bands on the disk. The times themselves were based on the disk already being up to speed. Given these seek times, it became quite apparent that any discontiguity in a file would be accompanied by a severe performance penalty, especially if the program were overlayed and required accesses between the different tracks. I thought about writing a 'squeeze' program, but since the Mac would probably be obsolete long before I completed it, here is an easier way to 'squish' the file structure: Simply insert a fresh disk and drag the old disk icon onto the new one, performing a disk to disk file copy. Since this is a file copy (not a sector copy), all fragmented files on the source disk will be transformed into contiguous files on the target volume, and any fragmentation will be eliminated. In addition, the various unallocated blocks scattered on the volume will be together at the end of the volume. I haven't experimented, but given the file allocation scheme currently in use, I would suspect that file create operations which previously failed would now work (i.e., the volume clipsize would no longer prevent file creation). As a quick test, I had a program which was fragmented into two pieces, and previously took 13+ seconds to load. After copying, the load operation took slightly less than 10 seconds. Not bad for no cost! This technique would work best on volumes which have lots of file creation and deletion activity, and are relatively full, but for the zero cost (other than a minute or so), it seems well worth the time. Now if Apple would only provide a utility which would allow me to place my files at specific places, so I could minimize track seeks... -- Ken Bates uucp : decwrl!dec-rhea!dec-bison!bates arpa : bates%bison.dec@decwrl cis : 70047,1226 enet : BISON::BATES phone: (303) 594-2039 mail : Digital Equipment Corp. 301 Rockrimmon Blvd. Colorado Springs, CO 80919