Deutsch English Français Italiano |
<v5dpa8$1ej8a$1@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Terje Mathisen <terje.mathisen@tmsw.no> Newsgroups: comp.arch Subject: Re: ancient OS history, ARM is sort of channeling the IBM 360 Date: Tue, 25 Jun 2024 08:49:43 +0200 Organization: A noiseless patient Spider Lines: 26 Message-ID: <v5dpa8$1ej8a$1@dont-email.me> References: <s7r87j1c3u6mim0db3ccbdvknvtjr4anu3@4ax.com> <v5an0l$10bj$1@gal.iecc.com> <87le2vatq4.fsf@localhost> <v5asis$p33t$1@dont-email.me> <v5dfkf$1h3e$3@gal.iecc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Injection-Date: Tue, 25 Jun 2024 08:49:44 +0200 (CEST) Injection-Info: dont-email.me; posting-host="45d4d75ee6b455bec7102832e175de7c"; logging-data="1527050"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19gdXcqBKBhxQaVN8LfnESZPm4tV1rbroH5X7CcGEpzoQ==" User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.18.2 Cancel-Lock: sha1:rA6VbqmxbzR3E7uZhwXo5d9hAdY= In-Reply-To: <v5dfkf$1h3e$3@gal.iecc.com> Bytes: 2313 John Levine wrote: > According to Lawrence D'Oliveiro <ldo@nz.invalid>: >> How much of theoretical disk bandwidth was the filesystem capable of >> using? Because I know early Unix systems were pretty terrible in that >> regard, until Berkeley=C3=A2=E2=82=AC=E2=84=A2s =C3=A2=E2=82=AC=C5=93F= ast File System=C3=A2=E2=82=AC=C2=9D came along. >=20 > My recollection is that if you were using QSAM with multiple buffers > and full track records it wasn't hard to keep the disk going at full > speed. Later versions of OS do chained scheduling if you have enough > buffers, doing several disk operations with one cnannel program. Even on (MS)DOS it was easy to saturate the hard drive from a single=20 program, you just needed large enough (i.e. at least a full track each)=20 buffers. I did end up making special file/record layouts which were optimized for = this, using exactly 4kB for each header+bitmap record. Terje --=20 - <Terje.Mathisen at tmsw.no> "almost all programming can be viewed as an exercise in caching"