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!!"