dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/12/86)
>> The moral is that if you find a deficiency in your OS, FIX IT IMMEDIATELY. >> ... >> It does not make sense to modify DOS: >> ... >> (C) Changing DOS would break everything in existance that does funny >> things with the disks, and probably more. >> >> >> -Matt >Isn't point C in conflict with the first line of the quotation (I hope I >didn't take it out of context)? It is precisely the matter of breaking >other innocent applications that makes the job of "fixing" deficiencies >so difficult (and doesn't make fixing bugs any easier either). > -Tony Sumrall Quite right. In real life it may not be possible (due to red-tape) to fix ALL the problems, So you pick the one you think will have the most repurcushions. If the Amiga is going to compete with the MAC for user- friendliness, I think Fixing the WorkBench should take precedence. Additionaly, fixing WorkBench is utterly trivial when compared to fixing DOS. In a WorkBench based enviroment, you even get a partial solution to the DOS problem indirectly.... there would be fewer files in the directory since all the .info files will go away. Taking that into account, I see two improvments for DOS that would alleviate the directory problem while keeping compatibility: (A) Change the sector allocation around directories such that DOS will attempt to reserve sectors around the Directory node for File Headers rather than File Data. Currently, small files are being written on the same track as Directory Nodes. With 11 sectors/side/track and two sides, you have access to 22 sectors without having to move the R/W head. Change the location of the sector maps so they are NEAR the sectors they map. Result: When you are loading a large program and it needs to get at the sector map for the next set of blocks it doesn't have to go far. (B) Add Configurable track buffering. This will DOUBLE THE SPEED of the floppies when loading large programs. Why? Because now you can DMA side 2 of the disk while your MFM decoding side 1. DON'T YOU WANT TO DOUBLE THE SPEED? This scheme is a simple and effective read-ahead. Additionaly, track buffering means that (1) a single program reading and writing in small chunks and (2) Two separate programs reading or writing to two separate files will gain an order of magnitude speed increase. (C) Remove sector buffering or use a better scheme. With the above, the current performance increase you get with sector buffering would become almost nothing, Since directory entries will be close to directory nodes and fall within the track buffering. Currently I've configured 30 buffers for DF0: and 30 for DF1:. The only thing I gain loading LC1 or LC2 (or anything else) is that after the second time around executing LC1, it loads about half a second faster. 60 Buffers is 5.45 tracks.. (11 sectors/track). That is memory-usage equivalent to 7 tracks of buffering (including the track for each of my two floppies which is already buffered in both the current and my thoretical system). With the above scheme I think I can get double the performance allocating 4 tracks for DF1: (where LC1 is) and 3 for DF0: and NO sectors. -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/14/86)
>In article <8610120047.AA18469@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> (A) Change the sector allocation around directories such that DOS >> will attempt to reserve sectors around the Directory node for >> File Headers rather than File Data. Currently, small files are >> being written on the same track as Directory Nodes. With > >Actually, we need both the directory's node, the file header block, and >the first sector of the file to be on the same track. >Unfortunately, this means that they would have to be on the same track as >the directory, which is on the same track with its junk, with the parent, >etc.etc. Nope, you didn't read my entire article because I addressed this "problem". >The real question is: Is the emphisis on file name expansion (keep file >headers near directory block, implies directory blocks are not with the >rest of its directory) or on icon display (keep the first sector of >data near the file header, and forget about the directory)? > > Michael Gersten >p.s. Note that (A) does not store all of a directory near the directory's >node, while (B) stores none of the names near the directory node. You >can't store all the names by the node as then all the names for the >entire disk wind up on one track. (B) seems like a fair compromise given >the file system limits. The point is to group them together *somewhere*. Multiple track buffering (later in my article), solves most of the problems. You could even add a flag settable on a file handle saying "this is a small file" to give does a little more info on what the hell your doing. -Matt