Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!daver!bungi.com!news
From: culberts@hplwbc.hpl.hp.com (Bruce Culbertson)
Newsgroups: comp.sys.nsc.32k
Subject: Re: sources?
Message-ID: <9101111841.AA02679@hplwbc.hpl.hp.com>
Date: 11 Jan 91 18:41:15 GMT
Sender: news@daver.bungi.com
Lines: 57
Approved: news@daver.bungi.com

bobm@pixel.convex.com writes:

> > Bruce C. and I are working on a minix 1.5 version that uses
> > most of the 1.3 kernel but all of the 1.5 fs and mm.  It allows 64
> > meg partitions
> 
> I appreciate what you're doing, and I'll undoubtedly buy a copy, but
> isn't a 64Mb partition kind of silly?  Most pc532's already have one
> or more 300 Mb disks, in a couple of years 1Gb drives will be common
> on home machines.

Silly?  Well, yes and no.

Andrew Tanenbaum had very specific objectives for Minix, among them that
Minix would run on computers which were cheap and plentiful.  The
minimal system he had in mind was an IBM-PC with floppies and without
hard disks.  To make a file system on a 360K floppy useful, the number
of disk blocks devoted to file system management had to be kept to a
minimum.  It follows that the i-nodes have to be small.  Since a large
part of an i-node is an array of block numbers, the block numbers had to
be small.  Tanenbaum chose 16-bit block numbers.  Since he also chose
1024-byte blocks, this resulted in a maximum file system size of 64
megabytes.  None of this was silly, I think.

Now, we come along with our 300 megabyte disks and use Minix.  I guess
that's pretty silly.  A new file system has been (is being?) defined
which will have 4-byte block numbers and i-nodes which are twice as
large.  This will appear in Minix 2.0, if not before.  The i-nodes will
also contain three dates instead of the current one date.  It will be
possible to mount both the new and old flavors of file systems at the
same time.

Phil Nelson was trying to make the point that Minix 1.5 fixes some
bugs which made the actual maximum partition size of Minix 1.3 32
megabytes.  64 megabyte file systems are less silly than 32 megabyte
file systems.

> Wouldn't it be easier to change all the shorts to longs now?

There is more to it than changing shorts to longs.  The i-nodes are
packed quite efficiently into a disk block and i-nodes never span a disk
block boundary.  Also, there is the issue of compatibility.  While I
bootstrapped the 32000 Minix port, it was extremely helpful to be able
to mount the same file system on either a working IBM-PC Minix system or
the new 32000 Minix system.  Furthermore, all the PC-Minix utilities
which know about the structure of a file system can be used on
pc532-Minix without change.

> BTW, I note that Bruce's gcc 1.35 recognizes "long long" (the 64
> bit integer) but that libc is missing some routines to support it.
> Did you, Bruce, have to do anything to support long longs, or did
> it just fall out of gcc for free?

It just fell out for free.  Is anyone interested in writing the
support routines?  I have not had occasion to use long-long's yet.

Bruce Culbertson