ast@cs.vu.nl (Andy Tanenbaum) (10/08/90)
I am trying to decide whether V2.0 should have 13 3-byte disk addresses in the inode or 10 4-byte disk addresses. The former allows files up to 10K to be "small," the latter puts the limit at 7K. However, 3-byte disk addresses require messy conversion when reading in or writing out an inode. UNIX uses the former scheme. In any event, I will allocate 3 of the inode slots for indirect blocks, although I probably won't put in the triple indirect block code now. It is a real mess for the case where you need a triple indirect block and the disk only has 3 blocks left, so you allocate the triple, double, and single indirect blocks, then fail trying to allocate a data block. If people have any opinions on the subject of 3-byte vs. 4-byte disk addresses on the disk, please post comments. In all cases, the in-core structure will hold 4-byte addresses for speed in using them. Andy Tanenbaum (ast@cs.vu.nl)
burgess%creek.decnet@hsdp2.brooks.af.mil (CREEK::BURGESS) (10/10/90)
In message (?) AST writes: > If people have any opinions on the subject of 3-byte vs. 4-byte disk > addresses on the disk, please post comments. In all cases, the in-core > structure will hold 4-byte addresses for speed in using them. Mr. Tanenbaum (ast@cs.vu.nl), I have always been a firm believer in internal consistency. If you are going to use 4-byte address in memory, why obfuscate the method and waste the time converting them back and forth reading them from disk? BTW, do you need any help with any of your Minix projects? My computer has arrived from Germany. Also, all who were waiting for the changes for the spurious "Out Of Paper" error, I will be sending them out this week. Dave Burgess burgess%creek.decnet@hqhsd.brooks.af.mil
UNM409%DBNRHRZ1.BITNET@cunyvm.cuny.edu (Volker A. Brandt) (10/11/90)
4 byte disk addresses seem more `natural' to me. ---------------------------------------------------------------------------- Bitnet: UNM409@DBNRHRZ1 Volker A. Brandt UUCP: ...!unido!DBNRHRZ1.bitnet!unm409 Angewandte Mathematik ARPAnet: UNM409%DBNRHRZ1.BITNET@CUNYVM.CUNY.EDU (Bonn, West Germany)
drl@vuse.vanderbilt.edu (10/11/90)
At the risk of being pedantic, I'll vote for 4 byte pointers on disk. I think that the 3 byte pointers may represent a micro-optimization and, as an educational tool, MINIX should go for clarity not cleverness (which I understand to be your position as well). David David Linn, System Manager/Postmaster |INET: drl@vuse.vanderbilt.edu Vanderbilt University School of Engineering|Phone: [+1] 615-343-6164 Post Office Box 3241, Station B |Disclaimer: Nashville, TN, USA 37235 | I speak only for myself.
V2057A%TEMPLEVM@pucc.princeton.edu (Juan Jose Noyles) (10/12/90)
I personally think that compatibility with the rest of the world is more important that clarity for the sake of academia. I've been out of school for some years now. I got interested in Minix because it seems to be a cheap, minimalist way to get into Unix, and I'm quite sure there are lots of people out here using it for the same reason. Perhaps if Dr. Tanenbaum surveys the Unix world, he'll get a better idea of which size to use and why.
lwj@cs.kun.nl (Luc Rooijakkers) (10/12/90)
burgess%creek.decnet@hsdp2.brooks.af.mil (CREEK::BURGESS) writes: > I have always been a firm believer in internal consistency. If you are going >to use 4-byte address in memory, why obfuscate the method and waste the time >converting them back and forth reading them from disk? The disk addresses have to be converted anyway from/to "standard" byte order on disk, to keep the various computers compatible. With 4 byte addresses you might use BSD's ntohl()/htonl() functions, but the conversion has to be done anyway. What's the difference between unsigned long blk; unsigned char *ptr; blk =*ptr++; blk<<=8; blk|=*ptr++; blk<<=8; blk|=*ptr++; and unsigned long blk; unsigned char *ptr; blk =*ptr++; blk<<=8; blk|=*ptr++; blk<<=8; blk|=*ptr++; blk<<=8; blk|=*ptr++; except for a few cycles ? Similar code exists in V7 (I know, I've seen it). I would say that the decision has to be made solely on "small files" versus "maximal disk capacity". Why repeat the 16-bit cluster number mistake of MS-DOS with 24 bits ? Of course, we're talking about zones, and with 1K zones 2^24 is already 16G... -- Luc Rooijakkers Internet: lwj@cs.kun.nl Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj University of Nijmegen, the Netherlands tel. +3180652271
brucee@runxtsa.runx.oz.au (Bruce Evans) (10/13/90)
In article <33146@nigel.ee.udel.edu> drl@vuse.vanderbilt.edu writes: >At the risk of being pedantic, I'll vote for 4 byte pointers on disk. >I think that the 3 byte pointers may represent a micro-optimization There would be no excuse for 3-byte pointers if the decision was just between 3 bytes and 4 bytes. However, it is planned for Minix 2.0 to support the 2-byte pointers in old 1.x file systems as well as 4-byte pointers in 2.0 file systems, and to byte-swap the pointers as required to handle disks written by all versions of Minix. The extra code for 3 byte pointers is relatively insignificant and the only complication is that there is no 3-byte integral type. 3-byte pointers save an indirect block for each file of size 8 blocks to 10 blocks. In one of my Minix file systems there are 62729 blocks used and 391 files in this range of sizes. 3-byte inode pointers would save only 0.6%. This is too small to justify complications. -- Bruce Evans (evans@syd.dit.csiro.au)