Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!styx!ames!ucbcad!ucbvax!RELAY.CS.NET!macmillan%wnre.aecl.cdn%ubc.CSNET
From: macmillan%wnre.aecl.cdn%ubc.CSNET@RELAY.CS.NET (John MacMillan)
Newsgroups: mod.computers.vax
Subject: disk compresses
Message-ID: <629*macmillan@wnre.aecl.cdn>
Date: Mon, 1-Dec-86 09:22:19 EST
Article-I.D.: wnre.629*macmillan
Posted: Mon Dec  1 09:22:19 1986
Date-Received: Tue, 2-Dec-86 07:44:38 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 31
Approved: info-vax@sri-kl.arpa

We have about 12 RA81's in a VAX cluster (8650, 785 and 2 750's). The user
population is around 400. The main programs are large simulations.

Disk fragmentation has become a problem, requiring disk compresses every
two weeks. Wierd program behaviour (like taking 3 to 4 times to run) was
observed before one of the compress sessions.

No-one is happy about losing the entire cluster for most of a day (10 hours+)
while the compress goes on (ie. operators working overtime, users, system
manager trying to keep costs down, etc.)

Is our situation normal? How often do other sites compress their disks?
What is the experience of other sites? Are there general guidelines to
reducing the frequency of compresses? What is the optimal way to organize
disks? (ie. number of user disks, system disks, scratch disks, where files
are stored, etc.)

We are about to retire a DECsystem-10 model KL. Ironically, disk compresses
on it were a rarity. No problems. 

So why does the VAX give so much trouble and what is the best way to deal with
it?

Thanks..

John MacMillan
Atomic Energy of Canada
Whiteshell Nuclear Research Establishment
Pinawa, Manitoba, Canada R0E 1L0

(204) 753-2311 x2539