Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-unix!sri-spam!ames!oliveb!sun!pepper!cmcmanis From: cmcmanis@pepper.UUCP Newsgroups: comp.sys.amiga Subject: Re: Making a custom Filing System Message-ID: <19347@sun.uucp> Date: Wed, 20-May-87 14:27:43 EDT Article-I.D.: sun.19347 Posted: Wed May 20 14:27:43 1987 Date-Received: Fri, 22-May-87 01:28:19 EDT References: <8705151922.AA05483@cory.Berkeley.EDU> <132@l5comp.UUCP> Sender: news@sun.uucp Reply-To: cmcmanis@sun.UUCP (Chuck McManis) Organization: Sun Microsystems, Mountain View Lines: 92 [ I have been *deep* inside the Amiga DOS file system and there are a few inaccuracies here that need to be pointed out...] In article <132@l5comp.UUCP> scotty@l5comp.UUCP (Scott Turner) writes: In discussing the Block format Scott says ... > 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. Scott is talking to people who want to write drivers here, if you ask for a block through DOS then DOS will check it's checksum for you. > 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 :). A couple of things, first the number of reserved blocks are stored in something called an Environment vector. It is documented in the exec/filehandler.h file. Don't hard code two into your routines. Second the Bitmap blocks also have a Checksum. Phillip Lindsay's description puts it as the first longword in the buffer. > 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). First the style comment, referring to various programs you dislike with slightly permuted names like AmigaDOG, Lettuce, etc appears on this end to be rather childish and petty. Let's try to be mature adults and minimize the editorializing shall we? Second, the packet Scott mentions is ACTION_INHIBIT. Sending this packet to a disk device with Arg1 set to TRUE causes it's icon to switch to the Dxx:BUSY icon. Note that if you do this the only way to read and write data to the disk are is with trackdisk calls. DOS and all other tasks are prevented from accessing your disk. The feature is of course that when you send it ACTION_INHIBIT with Arg1 set to FALSE it re-reads the label *and* the Disk.info file and redisplays the icon on the screen. Therefore if you want your program to change a disks icon 'on the fly' you can copy over your disk.info file, then INHIBIT and de-INHIBIT the drive and the workbench will pick up the new Icon. > 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? Scott you presuppose a disk controller. The current Amiga software cannot detect a corrupt sector. Paula reads in the bits and the blitter decodes them, then the driver pulls out the sector you want. No automatic CRC checking is done like on other systems. Also note that on a PC or ST the sector consists of a start of sector byte, track, and sector number, start of data, 512 bytes of data, and two bytes of CRC. so they are really 512+2+2+2 (518) bytes long. Yes it would be possible to make sectors on the Amiga with a Data Area 512 bytes long but that would needlessly complicate calculating where in the track buffer to read the data from. (sector * 536) anyone? The Checksum in the sector provides the same function as the CRC in everyone elses sectors. > 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. I suspect this is a safety feature. Ideally the new bitmap should be created in toto in 'new' blocks on the disk and then the bitmap pages pointers in the root block written. It is already easy to crash a track by popping the disk out at the wrong time or have the power go out. If you crash the bitmap the darn thing Gurus (80000000000B). So the risk is reduced to a window of one block write. > ...I suspect that the also redundent value stored in each block giving > it's sequence in the list is there to support sparse files. I suspect it is to make rebuilding the file system easier. It certainly helps in that respect. >Scott Turner And of course what posting would be complete without a signature ... --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.