Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uakari.primate.wisc.edu!ginosko!uunet!mcsun!hp4nl!star.cs.vu.nl!ast
From: ast@cs.vu.nl (Andy Tanenbaum)
Newsgroups: comp.os.minix
Subject: Re: Large Disks
Keywords: disks
Message-ID: <3463@ast.cs.vu.nl>
Date: 2 Oct 89 21:16:23 GMT
References: <233@vsserv.scri.fsu.edu>
Reply-To: ast@cs.vu.nl (Andy Tanenbaum)
Organization: VU Informatica, Amsterdam
Lines: 59

In article <233@vsserv.scri.fsu.edu> nall@nu.cs.fsu.edu (John Nall) writes:
>Just as a start, if one does mkfs /dev/hd2 40000" for example,
>an error occurs right off the bat, since the 40000 is read into
>a integer variable called "blocks" and is thus a negative number.
John- If you could find the places in mkfs that should be unsigned and get
that fixed, please post the cdiffs.  I am certainly very interested and
I am sure others are too.

>However, I would hope that with the release
>of Minix Version 2.0, there would be a compilation parameter
>(size_t??) which would allow a 32-bit integer to be used.  Also,
>if we MUST have hard-wired disk parameters, such as number of 
>heads, number of sectors, etc., etc., can they be put into a
>single #include file, rather than stuck willy-nilly into separate
>programs?

As far as I know, heads, tracks, etc should not be needed any more.
The only reason was to run mkfs, fsck etc stand-alone on floppy disk
systems.  As far as I am concerned, that is over, and mkfs and fsck
are just regular MINIX programs.  I don't believe any MINIX programs use
heads, tracks etc. any more, but correct me if I have missed something.

As to 32 bit disk address, I don't know if you understand what you just
said.  I suspect not.  Unfortunately, I know very well what you just said.
I haven't brought the subject up yet because it is an unpleasant one, but
invariably somebody else will see the problem too and bring it up, so I might
as well go first.

The MINIX i-node is 32 bytes.  This was designed to be frugal on a floppy
based system.  The 32 bytes contain 9 16-bit disk addresses and a few other
goodies.  Going to 9 24-bit addresses (like UNIX) takes up 27 bytes.
Since we also need the mode, at least one time (a long), a gid, uid, etc,
it is not going to fit.  Furthermore, POSIX really requires three distinct
times in the i-node, not 1 like MINIX has.  The implication of all this is
that we have to go to a 64-byte i-node.  Not that this is so awful, and
technically it is not a problem, but it does mean that the V2.0 file
system will not be compatible with the 1.x file system (choke!).  I have
been aware of this since I read the POSIX standard and saw that one must
have three times in the i-node, since the standard tells exactly when each
time is updated, and test suites can easily verify this.

What do people think about a 64-byte i-node with 3 times and 24-bit disk
addresses (32-bits is overkill, and I'd rather have 13 addresses in the
i-node, just like UNIX).  Due to the bit maps, the disk layout can't be
UNIX compatible, however.

An obvious question is how do people convert?  One thought is that you
first tar your entire file system to diskette in tar format (or PAX or
whatever we have at that time).  Then you build a new V2.0 MINIX boot
diskette, turn the computer off, and reboot.  Next step is mkfs on your
disk, erasing everything, and setting up a new file system with 64-byte
i-nodes.  Then you read back the tar diskettes.  I don't think I need
explain what happens if you make a mistake somewhere.

I'll bet you didn't realize what a can of worms you were opening with that
remark about 32 bits!  As to size_t etc, POSIX specifies quite a few types,
and I will try to use them.

Andy Tanenbaum (ast@cs.vu.nl)