Path: utzoo!attcan!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.arch Subject: Re: Sun bogosities, including MMU thrashing Message-ID: Date: 26 Jan 91 17:21:41 GMT References: <5257@auspex.auspex.com> <3956@skye.ed.ac.uk> <5390@auspex.auspex.com> <1991Jan21.225211.17757@gpu.utcs.utoronto.ca> <1991Jan24.193 Sender: aro@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 75 Nntp-Posting-Host: odin In-reply-to: suitti@ima.isc.com's message of 24 Jan 91 19:34:58 GMT On 24 Jan 91 19:34:58 GMT, suitti@ima.isc.com (Stephen Uitti) said: suitti> In article suitti> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: pcg> On 21 Jan 91 22:52:11 GMT, dennis@gpu.utcs.utoronto.ca (Dennis pcg> Ferguson) said: dennis> And I distinctly remember arguments being made at the time to dennis> the effect that the speed of the Berkeley fast file system dennis> (still a fairly recent innovation then) was almost exclusively dennis> due to the larger block size, and that the block clustering dennis> algorithm, which makes the supporting code complex and dennis> relatively CPU-intensive when writing, really was unnecessary. pcg> Yes, on that type of machine (stupid disc controllers, timesharing) pcg> that's true. The question: is the merit of the improvement because pcg> of fixed static clustering or because of its consequences in the pcg> case of sequential access? .... On rereading it I think I should have qualified a bit my comment. There are difficult issues like the interplay between sophisticated rotational latency clustering, stupid controllers, using a bitmap for free list, the hash based search for free space, and so on. suitti> Interactive Systems has a file system based on the V.3.2 suitti> (essentially V7) file system, but with bitmapped block suitti> allocation. [ ... and its wonderful performance, especially suitti> with clever disk controllers ... ] Well, yes, this is one of the cleverer approaches, because as you hint using a bitmap essentially gives you dynamic instead of static clustering. Thus just the use of a bitmap buys you almost all the performance improvement of the BSD FFS for a fraction of the cost and with just 1024 bytes per block and withotu causing problems for random access. As Stephen Uitti says later there are still problems with inodes, but for the time being we can be happy. suitti> The straight V.3.2 file system was so slow that a 386/25 with a suitti> 300 MB 17 millisecond average access disk drive was good for only suitti> a small number of engineers, about four. With the software suitti> change, you can really run thirty. Don't put the V7 filesystem down that much, for all its (later) regrettable aspects. It did have some good performance, if freshly rebuilt (the freelist was sorted for physical clustering). pcg> The billjoys will say "so what, sequential access is 80%, so we go pcg> for it, and damn the rest!". suitti> In billjoys defense, before this change, it was 100% slow, suitti> rather than just 20% slow. Here I pick a medium size nit, just for the sake of historical accuracy: as hinted above the performance of the traditional Unix filesystem was not that bad, if it was regularly straightened out, as the free list initially was in physical address order. The problem is that nobody did the straightening regularly. I remember reading Stonebraker in the Ingres retrospective and his repentance over using static ISAM indexes that needed periodic reorganization, instead of dynamic VSAM style ones that are self reorganizing, all because if properly reorganized static indexes have marginally better performance. He found out that nobody bothered to refresh the indexes periodically... suitti> [ ... describing a log based editor instead of a copy based one suitti> like, in different ways, vi or emacs ... ] Precisely what I think is the best organization! Especially for virtual memory. Another nice organization was used by the TSS/370 editor, which used VSAM (then called another way) for (memory mapped) files. -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk