ftp.barnyard.co.uk/2015.02.ftp.barnyard.co.uk.tar/ftp.barnyard.co.uk/cpm/walnut-creek-CDROM/ENTERPRS/CPM/UTILS/S/SORTDISK.ARK/PACK.DOC

Text File | 1988-02-29 | 8KB | 141 lines

.cw 10
PACK is a program for reorganising CP/M disks.  It is most useful for
hard disk users who want to improve system performance by speeding
access to frequently used files.  It ensures that all data belonging
to each file is contiguous on the disk.  It also allows the user to
specify that certain files or groups of files should not be moved, and
that other files or groups of files should be moved to the beginning
of the disk, where access to them is assumed to be faster (involving
less head movement to and from the directory).

As with all programs which reorganise a disk or its directory, you
should be extremely careful when using PACK. Only run it after you
have backed-up all data to a safe place.  You should do that regularly
anyway, as disasters can always occur, but if your system crashes
while PACK is running you will definitely have to restore the disk
from backup.  As far as I know PACK itself is bug-free (though I offer
no guarantee whatsoever), but power failures, hardware glitches or
itchy fingers on the RESET button will trash your disk.

PACK takes the fast and loose approach to the disk packing task.  It
first of all plans exactly what it is going to do, recording the plan
in an allocation group permutation schedule.  It then asks the user
for confirmation, and if given it permutes the groups and then updates
the directory to reflect the new situation.  Until the directory
update is complete the disk is in an undefined state and the system
had better not crash.  The time required obviously depends on how
disorganised the disk was and what its data transfer rate is.  On my
NEC D3126 it takes about 10 minutes to pack a badly fragmented 7MByte
partition.

The alternative approach to disk packing (taken by Steve Dirickson in
his RESTORE utility), is to keep the directory up to date while moving
data groups around the disk.  This means that the disk will probably
be intact if the program is interrupted, but it involves an inordinate
number of writes to the directory during the packing process.  This
slows the whole process down by a large factor, and increases the
probability that, if there is a power failure or unscheduled reset,
the system will be in the middle of writing a directory sector at the
time.  My philosophy is that packing is a potentially risky business,
and the quicker it is over with the better.

Writes to the disk are not checked by re-reading.  RESTORE does this
(and checks the CRC of the read-back data). If you have flakey disk
hardware you should concentrate on fixing it rather than using PACK.
If your BIOS caches disk blocks or tracks, read-after-write at the
user program level is pointless anyway.  Alternatively, put read-
after-write logic in your BIOS, so that all programs which write to
the disk benefit (and run like treacle). PACK does a lot of writing,
but is not fundamentally different from any program which writes to
disk; it has to trust that what it has written is successfully
recorded.

PACK reads and writes the disk (necessarily) via direct BIOS calls.
Sector read or write errors reported by the BIOS are treated as
follows.  During the initial directory scan any read error causes the
program to report the error and quit.  Read or write errors during theèpermutation phase cause the program to stop moving groups and try to
extricate itself as gracefully as possible.  The directory is fixed up
to reflect the moves that were accomplished.  The group that caused
the problem will generally end up allocated twice, so up to two files
may be lost.  A degree of DU3 wizardry is necessary to recover the
disk.  PACK reports which group could not be read/written.  Use the
DU3 M command to find which file the group is allocated to, erase that
file, then check with DU3 again to see if the group is still allocated
to another file and erase that one too if so.  Finally allocate the
group by hand or with a suitable utility to a BADSECT file to stop it
being used again.  The one or two erased files can be restored from
backup (you have got a backup, haven't you). Read or write errors
during the final directory update are ignored.  There is no way to
recover if the directory is flakey.

The write type is passed to the BIOS in register C using the following
strategy: 1st sector of group, C=2 (write unallocated data); remaining
sectors, C=0 (write normal); last sector of a directory group, C=1
(write to directory). Note that the first and intermediate writes to
directory groups are not declared as directory writes.  This
eliminates unecessary reading and writing of the directory groups by
the BIOS blocking/unblocking logic, and should be quite legitimate.  It
could be a problem if your BIOS has strange ideas about
blocking/deblocking though.  In that case you should set the byte at
location 010BH in PACK.COM to a non-zero value, which will force PACK
to pass C=1 on all directory writes.

The memory requirements of PACK in addition to the program itself are
4 bytes per allocation group on the disk (4*DSM) plus space for 2
allocation groups, so 40K of TPA is sufficient to pack a worst case
disk (5K program + 4*512 tables + 2*16K group buffers). The memory is
allocated before any changes are made to the disk, and if there is not
enough PACK says so and quits.  The directory is scanned a few times
during the planning phase, and as much as will fit is cached in the
TPA at that time.  Any excess is re-read from the disk on each scan.

PACK resets the disk via BDOS function 37 after packing it, so there
is no need to run DISKRST after PACK. BDOS will rebuild the allocation
vectors the next time the disk is logged-in.

PACK refuses to process a disk which the BDOS considers is read-only.

PACK is written to run under ZCPR3 with either CP/M 2.2 or ZRDOS 1.7
as the BDOS. It was developed using Echelon's ZAS/ZLINK assembler and
linker, and uses library routines from SYSLIB and Z3LIB.



Disk and directory sizes under CP/M 2.2 (and ZRDOS 1.7):

The contraints on disk and directory size in CP/M 2.2 are as follows.
There can be at most 2**16 (65536) logical sectors (@128 bytes) on the
disk.  The BDOS assumes it can use 16 bit arithmetic when calculating
sector numbers, and values in the random record field of the fcb are
limited to 16 bits.  This gives us the CP/M 2.2 file and disk sizeèlimit of 8MBytes.  CP/M 3 extends this to 32MBytes by using 2 more
bits in sector numbers.  There are two separate limits on directory
size.  The allocation groups reserved for the directory must be
representable in the 16 bits available in the disk parameter block
(AL0 and AL1 in DRI parlance). This gives a limit of 16 * Group size /
32 entries.  But the number of directory entries that can ever be
needed is also limited to one per allocation group when the disk is
full of minimal size files.  The number of files is then given by the
total allocation groups less those assigned for the directory.

Allocation      Max Disk    Max Groups   Max Number of Directory Entries
Group size      size        per Disk      16 Groups   1 entry per Group

    1K          256K          256           (512)          248
    2K            8M         4096           1024         (4032)
    4K            8M         2048          (2048)         2032
    8K            8M         1024          (4096)         1020
   16K            8M          512          (8192)          511

Therefore the worst case directory size is 65024 Bytes, on a disk with
a group size of 4K containing 2032 small files.  Worst case number of
groups is 4096

Author:

Frank Cringle
22 Ellens Glen Road
Edinburgh EH17 7QP
Scotland

[phone]