From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 9495 invoked from network); 2 Aug 2022 17:58:13 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 2 Aug 2022 17:58:13 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 62DC840259; Wed, 3 Aug 2022 03:57:50 +1000 (AEST) Received: from mail-wr1-f52.google.com (mail-wr1-f52.google.com [209.85.221.52]) by minnie.tuhs.org (Postfix) with ESMTPS id C89AB40106 for ; Wed, 3 Aug 2022 03:57:31 +1000 (AEST) Received: by mail-wr1-f52.google.com with SMTP id z17so14120026wrq.4 for ; Tue, 02 Aug 2022 10:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7OWu6JF2nS9z3wsgesufS++MC0pCrgndNzvU8eTXSaE=; b=VPgBYXQArdVNMDqVQwWE32pNJzAv205N60L+HVwXW3vUhH6H4X5ioohbEiXbwPiCDV cyzUOXl4NQSq35BEYK/61iHRmo6N1zK1K4q+T7OvmsRdYaYWW4f175WC3grLkblqAo99 vOfYw1OBqsnNHfbOy7bv9bJMvmXticRdFtKEsaqpYfxqA+TeKIdFbnisAf0/FfJlgfY2 la0c2j6C1vOQGEZp7VTCWoUZ7MDmqMkFe1SR9DsH/qus5d3a7Mp04fgCjx/PGhnfVI/T JdsijMcXmcCa4cXJ70ZZ9XwslHxlG4LsyMR54CkF0NsfCIn/74wZNCktq0Cza/tBf9G0 0lJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7OWu6JF2nS9z3wsgesufS++MC0pCrgndNzvU8eTXSaE=; b=C81ZCQVMRIisWtB2qyipop1towUuoGcUwXV5LYunKxKZ7FY7OyWR+wOYjzQS1K+uGm 26V8+CAcYpeLeeNeTa833FInolpqJiaQgcAi4F6ZsWv5DT1sBLIBl/IlyclLtTNd8Ejz dskkpVkPgLk788fA9oPL+D8kQGHxrGzFCvY9dsHUskbcdluATRJ12t1AF7/DPLdwveKL HYT26cXaham/CLXibg0+QLX6r1wjrtRIarWy1SYLtabloNi+YoXFxW1hmKi7mcd0lNUN LMXNtKJ3mkMno4jcNKlcor+77w9USI8Wo8V/reJKQx2+LV2txV+GOJIZ2RVM1ihbw0Ua Xp+w== X-Gm-Message-State: ACgBeo0eVmJbCkgmXYdTUXH5rmS8GwzYyTebWlS9antpTScplggu0t+C ZmkvaLaf7VQTha1r03dWJZmhkmITOQZ79PWtcEo= X-Google-Smtp-Source: AA6agR5K2Sb0zpB0VtsMj/SoHuisQlSLgiJF0k55WwkRCPqRAE8tpchd0aBc9ryQPCgWJ2ZqloWZW7dUtqiikQaR4bs= X-Received: by 2002:a5d:47a4:0:b0:220:600d:2b0f with SMTP id 4-20020a5d47a4000000b00220600d2b0fmr8216066wrb.407.1659462989943; Tue, 02 Aug 2022 10:56:29 -0700 (PDT) MIME-Version: 1.0 References: <20220731195702.ACC4218C0C1@mercury.lcs.mit.edu> In-Reply-To: From: Gavin Tersteeg Date: Tue, 2 Aug 2022 12:56:18 -0500 Message-ID: To: heinz@osta.com Content-Type: multipart/alternative; boundary="00000000000008976705e545d68f" Message-ID-Hash: XF52EVE7NRVVNMIOFOWPPXMMUCG62VR5 X-Message-ID-Hash: XF52EVE7NRVVNMIOFOWPPXMMUCG62VR5 X-MailFrom: gctersteeg@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org, jnc@mercury.lcs.mit.edu X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: LSX issues and musing List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000008976705e545d68f Content-Type: text/plain; charset="UTF-8" I was heavily considering using Mini-UNIX for this project, but picked LSX for a few reasons. The biggest reason is that Mini-UNIX has features that I don't really need, and I figured it would be easier to add what I wanted to LSX than remove what I didn't from Mini-UNIX. My target system (A Heathkit H11) does have the full 56K of memory, but I would like to get as much user space as possible. It will also be running on the equivalent of a RX02 disk system, not a high speed spinning disk that Mini-UNIX seems to expect. Regardless, if LSX proves to be too much of a hassle, I will probably just switch to Mini-UNIX. The inode allocation stuff seems to be what is causing the issues. When I mount the filesystem on stock V6, create a file, and then remount it on LSX, it (seems) to work again. Hopefully this code isn't too hard to add back, but if need be I can live with the 100 file limit. Unless I decide to try to get a hard drive hooked up, of course. Right now I am working on getting the hardware up and running again. I am hoping to bring all of this to VCFMW to show off, but since I have to go back to college in a few weeks I have a lot of work ahead of me. Thank you for the help, Gavin On Mon, Aug 1, 2022 at 12:37 AM Heinz Lycklama wrote: > Remember that the LSX and Mini-UNIX systems were > developed for two different purposes. > 1. LSX had limited resources available to it and thus > some general-purpose features had to be removed. > LSX supported some new features for the support > of real-time systems and intelligent terminals. The > features included contiguous files and asynchronous > read/write capabilities. > 2. Mini-UNIX was developed to run on PDP11/10 computers > without memory management support at the hardware level. > Larger main memory and faster larger disks were available. > It was designed to support up to four users at a time, and > thus needed to support the latest UNIX System features > without the additional features available on LSX. > > To answer the question below about kernel code to create > contiguous - the only change in the kernel code was to > recognize a contiguous file in the inode. The actual file > had to be created by a system program to keep the > kernel as small as possible. > > Heinz > > On 7/31/2022 12:57 PM, Noel Chiappa wrote: > > {I was going to reply to an earlier message, but my CFS left me with > > insufficient energy; I'll try and catch up on the points I was goibf to > make > > here.} > > > > > From: Gavin Tersteeg > > > > > This leaves me with about 1.9kb of space left in the kernel for > > > additional drivers > > > > I'm curious how much memory you have in your target system; it must not > be a > > lot, if you're targeting LSX. > > > > I ask because LSX has been somewhat 'lobotimized' (I don't mean that in a > > negative way; it's just recognition that LSX has had a lot of corners > > trimmed, to squeeze it down as much as possible), and some of those trims > > behind some of the issues you're having (below). > > > > At the time the LSI-11 came out, semiconductor DRAM was just getting > started, > > so an LSI-11 with 8KB onboard and a 32KB DRAM card (or four 8KB MMV11 > core > > memory cards :-), to produce the 40KB target for LSX systems, was then a > > reasonable configuration. These days, one has to really search to find > > anything smaller than 64KB... > > > > It might be easier to just run MINI-UNIX (which is much closer to V6, and > > thus a known quantity), than add a lot of things back in to LSX to > produce > > what will effectively be MINI-UNIX; even if you have to buy a bit more > QBUS > > memory for the machine. > > > > > > > the LSX "mkfs" was hardcoded to create filesystems with 6 blocks > of > > > inodes. This maxed the number of files on a disk to 96, but even > with > > > the maximum circumvented LSX would only tolerate a maximum of 101 > files. > > > > And here you're seeing the 'lobotomizing' of LSX come into play. That > '101' > > made me suspicious, as the base V6 'caches' 100 free inodes in the > > super-block; once those are used, it scans the ilist on disk to refill > it. > > > > The code in alloc$ialloc in LSX is hard to understand (there are a lot of > > #ifdef's), and it's very different from the V6 code, but I'm pretty sure > it > > doesn't refill the 'cache' after it uses the cached 100 free inodes. So, > you > > can have as many free inodes on a disk as you want, but LSX will never > use > > more than the first 100. > > > > (Note that the comment in the LSX source "up to 100 spare I nodes in the > > super block. When this runs out, a linear search through the I list is > > instituted to pick up 100 more." is inaccurate; it probably wasn't > updated > > after the code was changed. ISTR tis is true of a lot of the comments.) > > > > Use MINI-UNIX. > > > > > A fresh filesystem that was mkfs'd on stock V6 can be mounted on > LSX, > > > but any attempt to create files on it will fail. > > > > The V6 'mkfs' does not fill the free inode cache in the super-block. So, > it's > > empty when you start out. The LSX ialloc() says: > > > > if(fp->s_ninode > 0) { > > ... > > } > > u.u_error = ENOSPC; > > return(NULL); > > > > which would produce what you're seeing. > > > > Also, another problem with trying to 'push' LSX into a previously > un-handled > > operating regions (e.g. large disks, but there are likely others) is that > > there are probably things that are un-tested in that previously unused > > operating mode, and there may be un-found bugs that you trip across. > > > > Use MINI-UNIX. > > > > > Interestingly enough, existing large V6 RK05 images can be > mounted, > > > read from, and written to. The only limitations on these pre > existing > > > images is that if enough files are deleted, the system will > randomly crash. > > > > I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and > alloc.c), > > but I couldn't quickly find the cause; it isn't obvious. (When unlinking > a > > file, the blocks in the file have to be freed - that's inode 'ip' - and > the > > directory - inode 'pp' - has to be updated; so it's pretty complicated.) > > > > Use MINI-UNIX. > > > > > > > The information there about continuous files ... will be extremely > > > helpful if I ever try to make those work in the future. > > > > My recollection is that the LSX kernel doesn't have code to create > contiguous > > files; the LSX page at the CHWiki says "the paper describing LSX > indicates > > there were two separate programs, one to allocate space for such files, > and > > one to move a file into such an area, but they do not seem to be > extant". If > > you find them, could you let me know? Thanks. > > > > Noel > > --00000000000008976705e545d68f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was heavily considering using Mini-UNIX for this project= , but picked LSX for a few reasons. The biggest reason is that Mini-UNIX ha= s features that I don't really need, and I figured it would be easier t= o add what I wanted to LSX than remove what I didn't from Mini-UNIX. My= target system (A Heathkit H11) does have the full 56K of memory, but I wou= ld like to get as much user space as possible. It will also be running on t= he equivalent of a RX02 disk system, not a high speed spinning disk that Mi= ni-UNIX seems to expect. Regardless, if LSX proves to be too much of a hass= le, I will probably just switch to Mini-UNIX.

The inode = allocation stuff seems to be what is causing the issues. When I mount the f= ilesystem on stock V6, create a file, and then remount it on LSX, it (seems= ) to work again. Hopefully this code isn't too hard to add back, but if= need be I can live with the 100 file limit. Unless I decide to try to get = a hard drive hooked up, of course.

Right now I am = working on getting the hardware up and running again. I am hoping to bring = all of this to VCFMW to show off, but since I have to go back to college in= a few weeks I have a lot of work ahead of me.

Tha= nk you for the help,
Gavin

On Mon, Aug 1, 2022 at 12:37 AM H= einz Lycklama <heinz@osta.com> = wrote:
Remember = that the LSX and Mini-UNIX systems were
developed for two different purposes.
=C2=A0=C2=A0=C2=A0=C2=A0 1. LSX had limited resources available to it and t= hus
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 some general-purpose features h= ad to be removed.
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 LSX supported some new features= for the support
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 of real-time systems and intell= igent terminals. The
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 features included contiguous fi= les and asynchronous
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 read/write capabilities.
=C2=A0=C2=A0=C2=A0=C2=A0 2. Mini-UNIX was developed to run on PDP11/10 comp= uters
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 without memory management suppo= rt at the hardware level.
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Larger main memory and faster l= arger disks were available.
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 It was designed to support up t= o four users at a time, and
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 thus needed to support the late= st UNIX System features
=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 without the additional features= available on LSX.

To answer the question below about kernel code to create
contiguous - the only change in the kernel code was to
recognize a contiguous file in the inode. The actual file
had to be created by a system program to keep the
kernel as small as possible.

Heinz

On 7/31/2022 12:57 PM, Noel Chiappa wrote:
> {I was going to reply to an earlier message, but my CFS left me with > insufficient energy; I'll try and catch up on the points I was goi= bf to make
> here.}
>
>=C2=A0 =C2=A0 =C2=A0 > From: Gavin Tersteeg
>
>=C2=A0 =C2=A0 =C2=A0 > This leaves me with about 1.9kb of space left= in the kernel for
>=C2=A0 =C2=A0 =C2=A0 > additional drivers
>
> I'm curious how much memory you have in your target system; it mus= t not be a
> lot, if you're targeting LSX.
>
> I ask because LSX has been somewhat 'lobotimized' (I don't= mean that in a
> negative way; it's just recognition that LSX has had a lot of corn= ers
> trimmed, to squeeze it down as much as possible), and some of those tr= ims
> behind some of the issues you're having (below).
>
> At the time the LSI-11 came out, semiconductor DRAM was just getting s= tarted,
> so an LSI-11 with 8KB onboard and a 32KB DRAM card (or four 8KB MMV11 = core
> memory cards :-), to produce the 40KB target for LSX systems, was then= a
> reasonable configuration. These days, one has to really search to find=
> anything smaller than 64KB...
>
> It might be easier to just run MINI-UNIX (which is much closer to V6, = and
> thus a known quantity), than add a lot of things back in to LSX to pro= duce
> what will effectively be MINI-UNIX; even if you have to buy a bit more= QBUS
> memory for the machine.
>
>
>=C2=A0 =C2=A0 =C2=A0 > the LSX "mkfs" was hardcoded to cre= ate filesystems with 6 blocks of
>=C2=A0 =C2=A0 =C2=A0 > inodes. This maxed the number of files on a d= isk to 96, but even with
>=C2=A0 =C2=A0 =C2=A0 > the maximum circumvented LSX would only toler= ate a maximum of 101 files.
>
> And here you're seeing the 'lobotomizing' of LSX come into= play. That '101'
> made me suspicious, as the base V6 'caches' 100 free inodes in= the
> super-block; once those are used, it scans the ilist on disk to refill= it.
>
> The code in alloc$ialloc in LSX is hard to understand (there are a lot= of
> #ifdef's), and it's very different from the V6 code, but I'= ;m pretty sure it
> doesn't refill the 'cache' after it uses the cached 100 fr= ee inodes. So, you
> can have as many free inodes on a disk as you want, but LSX will never= use
> more than the first 100.
>
> (Note that the comment in the LSX source "up to 100 spare I nodes= in the
> super block. When this runs out, a linear search through the I list is=
> instituted to pick up 100 more." is inaccurate; it probably wasn&= #39;t updated
> after the code was changed. ISTR tis is true of a lot of the comments.= )
>
> Use MINI-UNIX.
>
>=C2=A0 =C2=A0 =C2=A0> A fresh filesystem that was mkfs'd on stoc= k V6 can be mounted on LSX,
>=C2=A0 =C2=A0 =C2=A0> but any attempt to create files on it will fai= l.
>
> The V6 'mkfs' does not fill the free inode cache in the super-= block. So, it's
> empty when you start out. The LSX ialloc() says:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0if(fp->s_ninode > 0) {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0u.u_error =3D ENOSPC;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0return(NULL);
>
> which would produce what you're seeing.
>
> Also, another problem with trying to 'push' LSX into a previou= sly un-handled
> operating regions (e.g. large disks, but there are likely others) is t= hat
> there are probably things that are un-tested in that previously unused=
> operating mode, and there may be un-found bugs that you trip across. >
> Use MINI-UNIX.
>
>=C2=A0 =C2=A0 =C2=A0 > Interestingly enough, existing large V6 RK05 = images can be mounted,
>=C2=A0 =C2=A0 =C2=A0 > read from, and written to. The only limitatio= ns on these pre existing
>=C2=A0 =C2=A0 =C2=A0 > images is that if enough files are deleted, t= he system will randomly crash.
>
> I had a look at the source (in sys4.c, nami.c, iget.c, rdwri.c, and al= loc.c),
> but I couldn't quickly find the cause; it isn't obvious. (When= unlinking a
> file, the blocks in the file have to be freed - that's inode '= ip' - and the
> directory - inode 'pp' - has to be updated; so it's pretty= complicated.)
>
> Use MINI-UNIX.
>
>
>=C2=A0 =C2=A0 =C2=A0> The information there about continuous files .= .. will be extremely
>=C2=A0 =C2=A0 =C2=A0> helpful if I ever try to make those work in th= e future.
>
> My recollection is that the LSX kernel doesn't have code to create= contiguous
> files; the LSX page at the CHWiki says "the paper describing LSX = indicates
> there were two separate programs, one to allocate space for such files= , and
> one to move a file into such an area, but they do not seem to be extan= t". If
> you find them, could you let me know? Thanks.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Noel

--00000000000008976705e545d68f--