Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!gatech!hao!ames!ucbcad!ucbvax!COGSCI.BERKELEY.EDU!bryce From: bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) Newsgroups: comp.sys.amiga Subject: Faster directories under AmigaDOS -> binary incl. Message-ID: <8705110932.AA29181@cogsci.berkeley.edu> Date: Mon, 11-May-87 05:32:57 EDT Article-I.D.: cogsci.8705110932.AA29181 Posted: Mon May 11 05:32:57 1987 Date-Received: Wed, 13-May-87 01:10:11 EDT Sender: usenet@ucbvax.BERKELEY.EDU Lines: 157 This article describes a easy way to get faster directories under AmigaDOS. The method described is: 1> 100% compatible. 2> Takes zero bytes of ram. 3> Works with existing disks -> no format changes. 4> Takes zero time to load. All it requires is a tiny li woah!!! EaThQuAke!!! (Good thing I don't live on landfill) (Darn California earthquakes are always interrupting things) (I would guess about 4.7 and from the south) ttle change to the source code to AmigaDOS; which sadly I do not have access to. :-( The dos function that gets the next directory entry is Brain_Dead (like most of the filesystem). It does many, many things as to guarantee that it is slow! Two examples: 1> It reads entries in HASH order; as far as the disk is concered this means RANDOM order. The dos could read one entry from Track 20 then another from 21 and then end up back at 20 for the next. 2> It reads *all* the extension blocks of a file for the purpose of counting the total blocks; since the filesystem will currently fill every block full except the last, a DIVIDE will do the same at much less cost. Here is a example snoop of a directory taken under the standard AmigaDOG filesystem: Block 880 -> Track 40 Head 0 Block 881 -> Track 40 Head 0 Block 882 -> Track 40 Head 0 Block 889 -> Track 40 Head 0 Block 891 -> Track 40 Head 1 Block 1011 -> Track 45 Head 1 Block 1013 -> Track 46 Head 0 Block 1039 -> Track 47 Head 0 Block 1041 -> Track 47 Head 0 Block 1082 -> Track 49 Head 0 Block 1089 -> Track 49 Head 1 Block 1180 -> Track 53 Head 1 Block 1183 -> Track 53 Head 1 Block 1184 -> Track 53 Head 1 Block 1186 -> Track 53 Head 1 Block 1199 -> Track 54 Head 1 Block 1186 -> Track 53 Head 1 Block 1200 -> Track 54 Head 1 Block 1202 -> Track 54 Head 1 Block 1273 -> Track 57 Head 1 Block 1296 -> Track 58 Head 1 Block 1299 -> Track 59 Head 0 Block 1301 -> Track 59 Head 0 Block 1303 -> Track 59 Head 0 Block 1305 -> Track 59 Head 0 Block 883 -> Track 40 Head 0 Block 1307 -> Track 59 Head 0 Block 1187 -> Track 53 Head 1 Notice how it goes from Track 53 to 54 to 53 to 54? That's 3 steps; a *LONG* time. Now take a look at what the program presented here does; Block 880 -> Track 40 Head 0 Block 881 -> Track 40 Head 0 Block 882 -> Track 40 Head 0 Block 883 -> Track 40 Head 0 Block 889 -> Track 40 Head 0 Block 891 -> Track 40 Head 1 Block 1011 -> Track 45 Head 1 Block 1013 -> Track 46 Head 0 Block 1039 -> Track 47 Head 0 Block 1041 -> Track 47 Head 0 Block 1082 -> Track 49 Head 0 Block 1089 -> Track 49 Head 1 Block 1180 -> Track 53 Head 1 Block 1183 -> Track 53 Head 1 Block 1184 -> Track 53 Head 1 Block 1186 -> Track 53 Head 1 Block 1187 -> Track 53 Head 1 Block 1200 -> Track 54 Head 1 Block 1202 -> Track 54 Head 1 Block 1273 -> Track 57 Head 1 Block 1296 -> Track 58 Head 1 Block 1299 -> Track 59 Head 0 Block 1301 -> Track 59 Head 0 Block 1303 -> Track 59 Head 0 Block 1305 -> Track 59 Head 0 Block 1307 -> Track 59 Head 0 It *SORTS* the blocks to reduce the number of needed seeks. It also DIVIDES the number of bytes to get the number of blocks in the file. (ie: It assumes each block is full -> a fair assumption considering the current filesystem and the relative unimportance of the information) It's not perfect; hash chains can force it to deviate, but it's better, and if properly implemented, totaly transparant. This program is not such a beast; it is a quick rehash of a program done back when I tried to convince Commodore to place such a change in V1.2. [Nothing happened]. It is not fully finished, I decided the old filesystem is incurable; and must be 'burried deep'. Fortunatly it is very clean to invent a *NEW* filesystem. To start it "RUN SPEEDDIR" from a CLI. It will replace directory handlers for drive DF1:. (Use a disk editor and change the string if you only have a DF0:) It works by patching the pr_PktWait field and handling packets of type ExNext. For each packet it gets, it sets up a brand new message port, ,calls Trackdisk, then deallocates things. It will leave the drive on after a read. -> NOTE <- I do not know how to link into the buffers that AmigaDOS keeps; this program is faster *WITHOUT* the use of cached blocks. If anyone can help me on this point; PLEASE DO! DISCLAIMER: This code is UNFINISHED, probably BUGGY, is UNCLEAN and is intended for use by HACKERS ONLY. Commodore-Amiga/Metacomo you are welcome to use these ideas for the next release -> but, better yet, write a *real* filesystem. ------------ Cut Here ------------- begin 777 speeddir M```#\P`````````!``````````````#;```#Z0```-LL>``$0_H#0$ZN_F@L/ M0"I`0?D```-2(@A.KO]22H!G```8*$!!^0```#PI2`!8+'@`!'``3J[^PG`5Y M3G5(YP`B+'@`!)/)3J[^V@:`````7"!`)$!.KOZ`($I.KOZ,($`B:``*($H,F M:0`8``IG!DS?1`!.=4S?1`!(YS#Z+'@`!"`I`!CE@"A`(#P```(`(CP``0`"' M3J[_.DJ`9P`!-B9`""P`!P!T9D@@/````2`B/``!``%.KO\Z*4``:&<``11"! MK`!L0JP`<"`4($MA``'\#),````"9@``]'!'($O1_````!@B;`!H(MA1R/_\Y M0I1*K`!H9P``\"`L`&QF+'#_-'P`$ MVV`8-'P`9V`2(FP`:"`\```!($ZN_RXT?`#H(#P```(`(DM.KO\ND\E.KO[:T M($`A2@"4(@I,WU\,9@1P_V`"<`!(YP`B+P<>.0"_X`$*!P`"$\<`O^`!+A\L0 M>``$(T``#"-!`!`@*0`$(T@`!")I```@0$ZN_I)@`/WX+PHB/``!``%P(DZN. M_SHD0$J`9Q1P_TZN_K9R_[*`9@XB2G`B3J[_+B1?<`!.=15```\5?`````X5- M?``$``A"*@`)D\E.KO[:)4``$$'J`!0@B%B00J@`!"%(``@@"B1?3G4O"7#_G M$T``""-``!1P`!`I``].KOZP(E]P(D[N_RY(YR`2+'@`!"0`)DB?_````#AP. M-R!/0AA1R/_\80#_8F=6+T``#A]\``4`"$'Y```#5R)/<`%R`$ZN_D1*@&8X& M/WP``@`<+WP```(``"1P">&B+T(`+"]+`"@B3TZN_C@B;P`.80#_?!`O`!_?` M_````#A,WT@$3G5P_TYU9&]S+FQI8G)A