Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty From: scotty@l5comp.UUCP Newsgroups: comp.sys.amiga Subject: Re: Making a custom Filing System Message-ID: <132@l5comp.UUCP> Date: Tue, 19-May-87 04:59:23 EDT Article-I.D.: l5comp.132 Posted: Tue May 19 04:59:23 1987 Date-Received: Thu, 21-May-87 02:39:35 EDT References: <8705151922.AA05483@cory.Berkeley.EDU> Reply-To: scotty@l5comp.UUCP (Scott Turner) Organization: L5 Computing, Edmonds, WA Lines: 82 Summary: More dirt and some answers. In article <8705151922.AA05483@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > 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 ripped RAM: apart and fooled around with it, like added relabel ram: support. But it's no picnic, better approach is via a PIPE: style 'handler'. > 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). It's real elegant except for those 24 byte headers at the front of each sector. Without these we could beam data straight from the disk into the user memory buffer. But instead we must read the sector into a private buffer and check its checksum, then crack the 488 bytes out of the sector and put them where the user wanted them in the first place. That isn't too elegant in my view. Bitmap blocks are very simple, they are a linear array of bits. The first bit is the first available block on the drive past the RESERVED blocks. On a floppy there are two reserved blocks so the first bit is block # 2. After that you just run sequentially up till ya hit the end of disk. The best way I found to get a feel for them is with a disk zap style program. Multi-tasking works out real well for this :). To keep the dog from sniffing the disk when it's inserted you send a dos packet to the drive's handler process. The packet ID and params are in the AmigaDOS technical reference manual from Bantam (mine is at work, sorry). > Lastly, I would have to be able to inform DOS when disks are >mounted/dismounted.. is it possible? Anybody have any ideas? You send a diskchange packet to the handler process for the drive involved. I don't think this one is in the Bantam book. It's in the dos header file with all the other ACTION_ definitions. >Waste in the Filing System: You forgot that idiot checksum at the front of every block on the disk. This is a real space and time waster. What they couldn't trust the disk system to figure out that a block was corrupted? >Inefficiencies due to DOS: The 1.2 amigadog also moves things around. While sniffing a hard disk to see how bitmaps work I noticed that it would MOVE the bitmap blocks as they were modified!!! Yuck. I've also seen some fun stuff happen with modified blocks of other sorts. I suspect that the dog releases the previous block used for the modified data and then hunts it up a new one from the current ALLOCATE ME NEXT thingie. > -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. Well, if they wanted to they could implement SPARSE files which would shoot a hole in your idea Matt. Both UN*X and Apple DOS 3.X support this concept, why not us? :-) It would be fun to throw a NIL block number in a slot in an extension block and see if the dog noticed it as a sparse block... > -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???? See above, I suspect that the also redundent value stored in each block giving it's sequence in the list is there to support sparse files. > -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!). The real problem here is that C-A only built in one track buffer per drive. The buffers from addbuffers are nice, but more TRACK buffers would be REAL nice! :) I did this on a CPM 68K system (added more track buffers) and had things speed up 4X that involved operations on multiple open files. You don't have to have two processes competing to have this problem, one process reading from one file and writing to another back and forth causes the same kinda thrashing. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)