Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ukma!gatech!prism!vsserv!nu.cs.fsu.edu!nall
From: nall@nu.cs.fsu.edu (John Nall)
Newsgroups: comp.os.minix
Subject: Re: Large Disks
Keywords: disks
Message-ID: <233@vsserv.scri.fsu.edu>
Date: 2 Oct 89 13:41:05 GMT
Sender: news@vsserv.scri.fsu.edu
Reply-To: nall@nu.cs.fsu.edu (John Nall)
Organization: Florida State University
Lines: 58

With respect to my previous message regarding problems using
large disks with Minix, apparently the meaning of the message
was somewhat ambiguous.  This message is intended both as a
summary of answers received, and as a clarification.

There are two issues regarding the use of large harddisks with
Minix.  (a)  Trying to use a large disk, but with no individual
partition greater than 32 MB.  This was the problem that I was
dealing with.  (b) Trying to use a Minix partition greater than
32 MB (on a large disk, obviously).

With regard to issue "a" the primary problem seems to be a 
failure of mkfs, evidenced by a message of "put_block unable
to write".  Andy pointed out that mkfs attempts to write the
very last block of the partition (being a non-trusting soul),
so the calculation has to be exact.  He also points out that
there are several different partitioning programs, and that
some are less honest that others.  So trust only fdisk from
Minix.  When mkfs gives this message out, it is because there
was a write(fd,buf,nbytes) which returned a value less than
nbytes.  In testing, I found that the value returned was very
consistently zero.  One person who replied to my message
mentioned that he had found that the values used by at_wini did
not necessarily correspond to the exact values of his disk, so
that at_wini thought he was being given a bad address while
trying to write the last block of the partition.  I have not
checked this out, since I solved the problem by a more careful
calculation of exactly how large the partition had to be (yes,
the whole thing was my stupid mistake!).

HOWEVER, with regard to issue "b", things get more interesting.
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.
I suspect that this is a fairly good indicator of the general
problem in this area -- that it is going to be a matter of going
through and locating the places where unsigned integers should be
substituted.  I'm willing to donate my system to trying to do this
for awhile (that is, a continual round of destroying the hard disk!)
so if someone wants to suggest anything, I'm game to try it.  In the
meantime, I'm going to start slogging through the code on my own, as
Andy requested, and will report whatever I find.

As an aside, it seems to me that shooting for a partition size of 64MB
is a reasonable thing to expect, so the 16-bit limit is not any
particular problem.  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?


======================================================================
John Nall                              Internet:  nall@nu.cs.fsu.edu
Computer Science Department            Florida State University
    "Today, a Moon Moth -- tomorrow, a Sea Dragon Conquerer!!"