[TUHS] LSX issues and musing

[Gavin Tersteeg]

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 <heinz at osta.com> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20220802/3b98b333/attachment.htm>