Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty From: scotty@l5comp.UUCP (Scott Turner) Newsgroups: comp.sys.amiga Subject: Re: Making a custom Filing System Message-ID: <139@l5comp.UUCP> Date: Fri, 22-May-87 09:10:21 EDT Article-I.D.: l5comp.139 Posted: Fri May 22 09:10:21 1987 Date-Received: Sat, 23-May-87 19:45:57 EDT References: <8705151922.AA05483@cory.Berkeley.EDU> <132@l5comp.UUCP> <19347@sun.uucp> Reply-To: scotty@l5comp.UUCP (Scott Turner) Organization: L5 Computing, Edmonds, WA Lines: 64 Summary: Comments on Chuck's comments, and a call for a new validator. In article <19347@sun.uucp> cmcmanis@sun.UUCP (Chuck McManis) writes: >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. Actually I was talking to people who want to SPEED the file system UP! >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. And as we shouldn't assume 2 reserved blocks, we shouldn't assume the disk has 1760 blocks on it either. Whenever I switch disk editors this is the SECOND thing I have to fix after I change the string used in open device from 'trackdisk.device' to the name of my hard disk driver. >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? Not this guy! I'm afraid AmigaDOG is here to stay for me at least. :) Also, the 'correct' name for the dos is trademarked and hence being good law abiding people we should make note of this fact when we use it. Much simpler to use AmigaDOG. >(sector * 536) anyone? The Checksum in the sector provides the same >function as the CRC in everyone elses sectors. Chuck, you assume I'm worried about speed on the FLOPPY drive! My hard disk drive system uses an ECC scheme which not only detects errors it attempts to FIX them. Hence the AmigaDOG checksum is literally a lead weight around the neck of hard disk drive systems. >I suspect this is a safety feature. Ideally the new bitmap should be [more text] >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. Whenever I get a crashed bitmap I get a repair session with the painfully slow disk-validator from the L: directory. Haven't had it guru me yet. Besides Chuck, the FLOPPY is written a TRACK at a time... This 'window of one block write' only applies on a hard disk system. Unless the dog has been naughty and scattered the bitmap from one end of the disk to the other. :) (I can't help it, but calling it dog rather than dos just leads to more effective mental images at times...) While I'm on the disk-validator... Anyone out there want to recode this thing? Two reasons: 1. The current one I think suffers from non-optimized disk seeks (just like examine_next) and has a VERY slow routine for rebuilding the map after it scurries all over the disk digging up data. 2. Once re-written it could be made available for use by people wishing to make PD bootable disks. Thus getting one more hurdle out of the way. Just think, we could kill two birds with one stone. Faster rebuilds, and peace of mind for C-A corporate. >I suspect it is to make rebuilding the file system easier. It certainly >helps in that respect. So do the NEXT pointers Chuck. The NEXT pointers give the sequence information for rebuilding as well. BUT NOT for a "sparse" system since there's no way for these NEXT pointers to encode a block that isn't there... :) 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)