Xref: utzoo comp.unix.questions:11139 comp.unix.wizards:14173 Path: utzoo!attcan!uunet!lll-winken!ames!mailrus!purdue!decwrl!pyramid!prls!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.unix.questions,comp.unix.wizards Subject: Re: Accounting woes for HCX/UX 3.0 Keywords: comp_t Message-ID: <11334@winchester.mips.COM> Date: 17 Jan 89 07:32:47 GMT References: <1356@mtunb.ATT.COM> <217@h.cs.wvu.wvnet.edu> <1358@mtunb.ATT.COM> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 53 In article <1358@mtunb.ATT.COM> jcm@mtunb.UUCP (was-John McMillan) writes: ... > >It strikes me the ORIGINAL writers were WELL prepared for the future -- >that they had an appropriate eye out for conserving resources, regardless >of disk sizes. With time, the sizes have increased -- my PC has 190 MB -- >but the lack of space never seems to be solved! ... >The average accounting file is read once or twice in its life: data >compression is reasonable and appropriate here. An error -- such as your >experience suggests exists -- is all the worse as I believe the compression >feature has been present for 15 years. The code was written early in 1978; DMR came up with the comp_t format; I wrote most of the original accounting software. At the time, most BTL UNIX machines were PDP-11/70s, usually with a couple RP04s (80MB), or maybe, RP06s (170MB). Typical main memory sizes were 256KB-1024KB; the kernel was limited to 64KB of code, 64KB of data, and (sometimes) 64KB of buffer cache. The design was of course geared to saving disk space, with the following reasoning: a) Typical peak fork/exit rates were 10/second. Such rates were often seen on the big PWB/UNIX systems that provided much of the impetus for doing the accounting in the first place. b) At 32 bytes/exit, this creates: 320 bytes/sec 19,200 bytes/min 1,152,000 bytes/hour 27,648,000 bytes/day c) Of course, few systems would actually run at that rate all day. Nevertheless, even a lesser, realistic rate could eat a 6th-edition filesystem, and it was required that this package run compatibly on PWB/UNIX 1.2 (which was still 6th-edition). Recall that each file was limited to 1MB, which could be overrun in an hour.... Of course, 7th-ed files and filesystems were bigger, but they didn't increase the size of disks... d) It was highly desirable NOT to go to the next higher power-of-2, as there really existed systems where doubling the accounting space would really make it impractical to use. Why would one go to 64, rather than a smaller number? ANS: for various reasons, it was desirable to keep an integral number of acct records per 512-byte block. The issue had nothing in particular to do with floating-point conversions, unless my memory fails me, strictly space compression. -- -john mashey DISCLAIMER: UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086