Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!wuarchive!zaphod.mps.ohio-state.edu!lavaca.uh.edu!jetson.uh.edu!honp9 From: honp9@jetson.uh.edu (Jason L. Tibbitts III) Newsgroups: comp.sys.amiga.hardware Subject: Message-ID: <6900.26ebac61@jetson.uh.edu> Date: 10 Sep 90 20:08:16 GMT References: <6499@sugar.hackercorp.com> <1159@mpirbn.mpifr-bonn.mpg.de> <14260@cbmvax.commodore.com> <1990Sep8.050725.14384@zorch.SF-Bay.ORG> <1990Sep08.210559.19597@ecst.csuchico.edu> Organization: Blob Shop Programmers Lines: 130 In article , Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) writes: [Much deleted] [RE: Floppy Disk Head Gronking] > Anyone who really uses AmigaOS's multitasking and doesn't have a hard disk > will see this a _lot_. It's loud and it's slooooow. My experience was > that the drive often would spend more time thrashing than actually > transferring data. Hard disks only thrash faster. IMHO, two programs run > simultaneously on the same CPU should not take significantly more time than > running each sequentially. You've got a partial solution, which is read buffering. Addbuffers is OK, FACC II is better. But you still need the initial read of the data to get it buffered in the first place. How about: A program that, upon detection of an inserted disk, allocates enough memory and starts reading data during periods of inactivity. It would also buffer all other reads. Of course, there is the problem of getting the disk out when you are done with it, but it isn't. You'd have to ask its permission to pop the disk out. There is a partial solution. Here's another: A buffer program that doesn't just buffer each sector, but the whole track as it is read. This would really help in situations where program A wants sectors 131 through 150, at the same time that program B wants sectors 999-1150. Instead of seeking back and forth, you'd only have to seek once for each track. > AddBuffers (and other caching programs) are great when you repeatedly > access the same file(s). However, there are a lot of "filter" programs out > there that: > > while (NOT EOF) { > read some data; > crunch the data; > write some data; > } > > If you're simultaneously running several of these babies (e.g. from > scripts), the cache isn't going to help a great deal. How about the above? Opinions? [RE: It's the controller manufacturer's responsibility, not CBM's] > Except the controller companies don't dictate the inherent > stability/fragility (e.g. write locks surviving a reboot) of the FS they > must support; CBM does. > OK. Let's think about this. How can your locks survive a reboot? A power failure? DO they really need to survive a reboot? I do quite a bit of 2400 baud downloading. It takes over 10 hours in some cases. I've lost power many times. Has there been problem ONE with my HD? Nope. Just delete the zero length file and continue. Do you still want the data? What you got is still there. I've extracted it. So what's the problem? [RE: Getting your hard drive trashed] > Well, _I_ don't have to try very hard. Try turning off your machine > _while_ an application is in the middle of writing a large file, and tell > me what you find when you reboot. Alternately, write a small program that > opens a file for writing then exits without closing the file. Now try to > access the file. Any problems? I did. I'd be impressed if any home machine could still resurrect the data if the heads are pulled from the platters in the middle of a write. Back to this in a minute. If a program exits without closing, you have a zero length file. Just delete it. (If the lock is still open, leave it there until you reboot, then delete it.) I can't see how the system is supposed to help this. Should it close the file for the program? (Hello resource tracking!) So you've got a zero-length file. The data on the rest of the disk is still secure. Back to the power failure: If you were actually writing data when you lost power, you will probably get a validation error. Here we agree: we need Fsck. (Triple underline 'need'.) I've had this happen a few times: the old head-glue problem with my OLD (One of the first) Quantum 105S drives. I have NEVER lost data. The disk validation error prevented me from writing and data. Thus, I could not munge any data that wasn't accounted for. I just pull out DiskX (thanks, Steve!) and repair the disk. Big deal, takes five minutes. I may be able to work up some kind of tutorial or instructions on doing this, it there is intrest. [Much deleted] > Fsck is overdue for AmigaOS, IMHO. The problems are well known as are the > solutions. How about a discussion of _how_ to implement it (or why it > can't be done), instead of why it would (not) be valuable? OK. Fsck is needed, and I believe FixDisk does a pretty good job. I prefer DiskSalv, but we want to fix the problem in place. So we start with FixDisk. What's wrong with it? Well, it was made for floppies, but won't work on large partitions. The author obviously has no big drive with which to test the program. He hasn't coded for extension bitmap tracks. (That's why the 48 meg limit on disk-fixing.) I believe that FixDisk has the proper understanding of the file system needed for an Fsck-type program. It also understands VERY well the floppy media and hardware. What it also needs is understanding of SCSI and hard media. (It needt to force re-mapping of blocks, track-wiping, and re-formatting of single tracks, if SCSI allows this.) SCSI-Direct is here, and it is standard. So how about it. Is FixDisk a good start? Or is DiskSalv a better base? I could not possibly begin to code any of these enhancements. BUT: I have an 80-meg Quantum which I might be persuaded to LOAN to the author of FixDisk, or another developer, for testing pruposes. I can't part with the thing forever, but I'm willing to loan it IF my sacrifice can further the Amiga community. If someone can send me the E-Mail address of the FixDisk author, or can get it in touch with him, I'd be very appreciative. > #include You got it there, Chuck. Now mine: ----====This is not written in the interest of flaming. I simply want these ideas to mature====---- So lets get to work... > -- > Chuck Phillips MS440 > NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com > 2001 Danfield Ct. > Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp -- \/ Jason L. Tibbitts III // | THEnet: {George|Jane|Elroy|Judy}::HONP9 /\/"Blob Shop Programmers: // | SesquiNet, Telnet, etc: HONP9@JETSON.uh.edu \/ Because We're Bored!" \X/ | CREN (BitNet): HONP9@UHVAX1 "Ewige /\ . DISCLAIMER ." Whose opinions did you think there were?" ; Blumenkraft"