The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: Jonathan Gray <jsg@jsg.id.au>
To: Kenneth Goodwin <kennethgoodwin56@gmail.com>
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>, tuhs@tuhs.org
Subject: [TUHS] Re: 'Huge' file support removed from PWB1
Date: Thu, 9 Mar 2023 23:40:38 +1100	[thread overview]
Message-ID: <ZAnTxlRMDPzvTqih@largo.jsg.id.au> (raw)
In-Reply-To: <CAMQbRb3ObGJ_ASJKDpDsdXbr0xrSD9knN-1mXZhsU-gStyQ3ZQ@mail.gmail.com>

removed in PWB/UNIX 1.0.

ifdef'd out in the Harvard/Radcliffe Student Time-sharing System (HRSTS)
parts found in tuhs/Applications/Usenix_77. h/distrib.note includes:

'4.	"Huge" files are not supported by our modifications.  This is not
necessarily a hard restriction, however we early on decided
we wanted no more than one level of indirection all the way up to 1 megabyte,
and had no need for larger files.  The incompatibilities may be minimal,
but we have not even bothered to seek them out.'

On Thu, Mar 09, 2023 at 03:21:19AM -0500, Kenneth Goodwin wrote:
> I have not seen the UNIX kernel source code in quite a while, but as I
> recall the double indirect block algorithm did not kick in until the file
> exceeded a certain threshold. So it would not make sense to remove the code
> for performance reasons.
> 
> Perhaps this is more likely due to the use of larger logical block sizes....
> 
> Is the code physically removed or IFDEF'd out for conditional compilation?
> 
> Perhaps someone decided that programmers would never need to test code on
> large files..
> 
> On Wed, Mar 8, 2023, 8:10 AM Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
> 
> > In PWB1, support for 'huge' files appears to have been removed. If one
> > compares bmap() in PWB1'S subr.c with V6's, the "'huge' fetch of double
> > indirect block" code is gone. I guess PWB didn't need very large (>
> > 8*256*512
> > = 1,048,576 bytes) files? I'm not sure what the _benefits_ of removing it
> > were, though - unless PWB was generating lots of files of between 7*256*512
> > and 8*256*512 bytes in length, and they wanted to avoid the overhead of the
> > double-indirect block? (The savings in code space are derisory - unlike in
> > LSX/MINI-UNIX.) Anyone know?
> >
> >                 Noel
> >

  reply	other threads:[~2023-03-09 12:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-08 13:10 [TUHS] " Noel Chiappa
2023-03-09  8:21 ` [TUHS] " Kenneth Goodwin
2023-03-09 12:40   ` Jonathan Gray [this message]
2023-03-09 15:07   ` Ron Natalie
2023-03-09 15:13     ` Ron Natalie
2023-03-09 17:35     ` arnold
2023-03-09 17:01 ` Tom Ivar Helbekkmo via TUHS
2023-03-09 23:25 ` Clem Cole

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZAnTxlRMDPzvTqih@largo.jsg.id.au \
    --to=jsg@jsg.id.au \
    --cc=jnc@mercury.lcs.mit.edu \
    --cc=kennethgoodwin56@gmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).