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)