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