From: firstname.lastname@example.org (Noel Chiappa)
To: email@example.com, firstname.lastname@example.org
Subject: [TUHS] Re: LSX issues and musing
Date: Wed, 3 Aug 2022 11:17:09 -0400 (EDT) [thread overview]
Message-ID: <20220803151709.E4CA718C0CF@mercury.lcs.mit.edu> (raw)
> 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.
'Speak of the devil, and hear the sound of his wings.'
>> From: Gavin Tersteeg
>> 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
> 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.
I don't know if the following is _the_ cause of the crashes, but another
problem (another aspect of the '100 free inodes cache' thing) swam up out of
my brain. If you look at V6's alloc$ifree(), it says:
if(fp->s_ninode >= 100)
fp->s_inode[fp->s_ninode++] = ino;
LSX's is missing the first two lines. So, if you try and free more than 100
inodes on LSX, the next line will march out of the s_inode array and smash
other fields in the in-core copy of the super-block.
Like I said, this is not certain to be the cause of those crashes; and it's
not really a 'bug' (as in the opening observation) - but the general sense of
that observation is right on target. LSX is really designed to operate only
on disks with less than 100 inodes, and tring to run it elsewhere is going to
run into issues.
How many similar limitations exist in other areas I don't know.
> From: Heinz Lycklama <email@example.com>
> Remember that the LSX and Mini-UNIX systems were developed for two
> different purposes.
Oh, that's understood - but this just re-states my observation, that LSX was
designed to operate in a certain environment, and trying to run it elsewhere
is just asking for problems.
next reply other threads:[~2022-08-03 15:17 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-03 15:17 Noel Chiappa [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-08-05 4:35 Paul Ruizendaal via TUHS
2022-07-31 19:57 Noel Chiappa
2022-08-01 5:37 ` Heinz Lycklama
2022-08-02 17:56 ` Gavin Tersteeg
2022-08-03 4:32 ` steve jenkin
2022-08-03 4:55 ` Ron Natalie
2022-08-03 5:09 ` G. Branden Robinson
2022-07-11 23:47 Noel Chiappa
2022-07-15 8:07 ` Gavin Tersteeg
2022-07-27 8:02 ` Gavin Tersteeg
2022-07-27 16:24 ` Heinz Lycklama
2022-07-30 4:39 ` Gavin Tersteeg
2022-07-11 21:47 Paul Ruizendaal via TUHS
2022-07-11 21:24 Noel Chiappa
2022-07-11 21:37 ` Gavin Tersteeg
2022-07-11 21:06 Noel Chiappa
2022-07-11 19:47 [TUHS] " Gavin Tersteeg
2022-07-11 20:01 ` [TUHS] " Warner Losh
2022-07-11 20:26 ` Clem Cole
2022-07-11 20:30 ` Warner Losh
2022-07-11 20:37 ` Phil Budne
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).