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