Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!ginosko!uunet!mcsun!hp4nl!nikhefh!n62 From: n62@nikhefh.nikhef.nl (Klamer Schutte) Newsgroups: comp.os.minix Subject: Re: Large Disks Keywords: POSIX stat inode Message-ID: <275@nikhefh.nikhef.nl> Date: 3 Oct 89 09:50:49 GMT References: <233@vsserv.scri.fsu.edu> <3463@ast.cs.vu.nl> Reply-To: Schutte@nikhefh.nikhef.nl (Klamer Schutte) Organization: Nikhef-H, Amsterdam (the Netherlands). Lines: 42 In article <3463@ast.cs.vu.nl> ast@cs.vu.nl (Andy Tanenbaum) writes: #>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. 24 bit addresses are not to efficient on a 68000: needs a lot of shift operations to come a decent integer type (long/short). #>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 Where is that in the standard? In my version (1986) paragraph 5.6.1.2 says: Only st_mode, st_ino, st_dev, st_uid, st_gid, st_size and st_mtime are requiered data elements in the stat structure. All other elements are optional, ... (etc.) So reading this whole section i think we are POSIX-compatible if we delete the fields st_atime & st_ctime from stat.h! #>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. where can i find this? <...> #>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. Saver will be: write a program which reads the old file system when running the new kind. And mount first only new type file systems. Just then mkfs the old file systems when you are sure you have transferred the old data. #> #>Andy Tanenbaum (ast@cs.vu.nl) Klamer. -- ____________________Yes, mail address changed again :-(_________________________ Klamer Schutte mcvax!nikhefh!{n62,Schutte} {Schutte,n62}@nikhef.nl