Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!think!ames!ucbcad!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Making a custom Filing System
Message-ID: <8705151922.AA05483@cory.Berkeley.EDU>
Date: Fri, 15-May-87 15:22:01 EDT
Article-I.D.: cory.8705151922.AA05483
Posted: Fri May 15 15:22:01 1987
Date-Received: Sun, 17-May-87 00:27:25 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 66


	I figure all I have to do is write my own driver (ala RAM:) which 
accesses the trackdisk for DFx:, making DOS forget about that particular 
drive (ala however diskcopy/format/disked do it).  I would like to use the
same filing system format for compatibility.

	I've been able to figure out the entire filing system disk format
(apart from some space wastage, it is quite elegant) except for the format of
the BITMAP blocks.  Anybody know what their format is ????  Also, how does
one take over a drive (just point me in the right direction).

	Lastly, I would have to be able to inform DOS when disks are 
mounted/dismounted.. is it possible?  Anybody have any ideas?

-----------------
Waste in the Filing System:

	-Extension blocks use 72 longwords to hold block numbers.  There is
	 a segment in the extension block of 46 longwords that isn't used
	 at all!!!! and it is even contiguous with the 72 longword block
	 ptr segment!!!!  I.E.  right now extension blocks can hold pointers
	 to up to 36K of data, but with almost no modification they can hold
	 pointers to up to 60K

	 possibly fixable without loosing compatibility with the current DOS.

	-The various types of blocks in the filing system use an 
	 almost-uniform format, but it is incredibly wasteful... using 
	 longwords to hold what could be 4 bit type fields.  Specifically,
	 the primary and secondary type fields could be combined.

	 not fixable unless you change the filing system format.

	-Some fields are defined but not used by the filing system.  In a
	 file header, there is a 'data size' field which is defined to be
	 the number of data block slots used, but DOS always sets this to 0.

	 Possibly upward compatible, assuming the current DOS ignores the 
	 field and later versions check the field against 0 and update it
	 to the proper value.

Inefficiencies due to DOS:
	
	-Why does a directory search go through all the extension blocks for
	 a file???  To count the number of actual blocks used by that file.
	 But, as Bryce pointed out, it doesn't need to do that... simply
	 divide the filesize by 488 to get the number of blocks.

	 And Get this:  Remember the field that was defined and not used???
	 guess what a good use would be... you got it. 

	-Why does DOS bother to read in extension blocks when loading large
	 files sequentially when it can simply use the 'Next Data Block'
	 field in the data blocks????

	-Why doesn't DOS do a top-level sort of the hash table when getting
	 directories?

	-Why does DOS compete with itself when multiple processes read and
	 write to disk simultaniously???  Even if each of two processes are
	 using an 8K block size, DOS will still do disk operations in 512
	 byte sizes (causing it to seek back and fourth when it really doesn't
	 need too!).


					-Matt