Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!mailrus!uunet!cs.utexas.edu!swrinde!mips!twg.com!david From: david@twg.com (David S. Herron) Newsgroups: comp.sys.amiga.hardware Subject: Re: Obsessive Multitasking and Amiga File I/O Scheduling Message-ID: <7915@gollum.twg.com> Date: 9 Sep 90 20:05:49 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> Reply-To: david@twg.com (David S. Herron) Organization: The Wollongong Group, Palo Alto, CA Lines: 118 In article <1990Sep08.210559.19597@ecst.csuchico.edu> mrush@cscihp.UUCP writes: >In article <1990Sep8.050725.14384@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: ... >>I didn't think my use patterns were that unusual, but maybe so. >> >>Yesterday, in a fairly typical setup, I had half a dozen shells open on >>the (A2000,1.3) workbench, doing various combinations of zoo -add, >>zoo -extract, lharc a, lharc x, interactive dir-s and info-s and list-s >>to make sure I wasn't clobbering Rad:, and on another screen, vt100 >>running to do downloads. >> >>Slow as molasses, on a 68000, but productive as heck, since I could read ... > Multitasking was EXACTLY the reason I bought my first Amiga, and I >haven't had that much trouble thrashing disks. Sure, if you have multiple >tasks that are accessing different cylinders on the same floppy there's going >to be some head movement. Disk heads thrashing around the disk as different processes tell it to go different places is one cause. Picture in your mind .. remember that Star Trek episode where you had a bunch of psychics who were all powerful on this planet and the shorty who was run around this way and that a complete non-psychic. Remember how he'd run this way and that back and forth as different of the bastards got ahold to him.. that's approximately what's happening with your floppies, Kent. The other part of what's going on is that you're spending a *LOT* of time in the process scheduler ... *any* multi-tasking system will, if you give it too many processes to run, become scheduler-bound. Don't believe me? Check out OS theory books.. Finally -- there's only so many CPU cycles available in any one machine. And besides the number of cycles you have to take into account the quality of the cycles -- how much work can be accomplished in one clock cycle? > But that's why Amiga floppies have that extra little >circuit board that PC floppies don't have -- so the drives can be individually >controlled! Eh? Are you sure? The only extra PC board I knew of was a simple ID circuit which would respond with some code indicating what kind of drive it is. My impression of the hardware interface is that it doesn't prevent access to multiple floppies at the same time. It's just that most of the machines which have multiple floppies (the PC class of machines) also don't run multi-tasking OS's. Which makes it harder to create a condition where you're *trying* to access multiple drives at once. > If you don't wanna bang your heads around, get a second (or third, or >fourth) floppy. Or as you're doing, use a ram disk. That's a good idea too.. One of the classic ways of speeding up Unix systems is to get another drive and split your busy disk partitions evenly among the two drives. That way you get some parallelism working for you in having multiple disk arms moving at the same time. ... >>Along with the deadly repeated "key error, backup, reformat and reload" >>problems reported here so often, this is another market killer for the >>business marketplace (which surely won't tolerate the unreliable hard >>disk problem like a crowd of hackers/students ready to do the "repairs" >>themselves will), and both need fixes Really Soon. ... > I don't think CBM can be held responsible for Hard Disks that get >trashed because of programs failing during Writing. This is more the >responsibility of the companies that manufacture the Hard Drive controllers >and associated drivers. Regardless of whether or not application programs are poorly written the file system should be more resistant to being trashed. Yes, in theory, there isn't a lot that can be done if a process goes insane since there isn't any protection in the machine. My impression is that the file system is one of the WEAKEST links in this system. But then I had a long episode last year where my disk got trashed for some odd reason, so I repaired it and it got trashed again shortly afterward, and I repaired it again, and it trashed again and.. Like Kent, I would be very happy if an `fsck' were available. What `fsck' means is: Fixes the disk in place. Finds files and directories which are `inconsistent' and does a best attempt at recovering the file and putting it *somewhere* in the file system. If it can't find its original place(es) then put it into a standard place (`lost+found') with some rationally constructed name. Dave's program (DiskSalv) is pretty good but it *DOES* *NOT* do it "in place" meaning I gotta have another disk to recover files to. But I only have one hard disk in my system sooo.. It helps a lot if the file system is resilient. For instance if there is some critical information somewhere you can try repeating it at regular spots on the disk. The Berkeley Fast File System does this, it repeats the "superblock" at the head of each cylinder group (cyl-group == 8 or 16 cylinders). When viewed from the correct level of abstraction a file system, or any other part of a computer system, is just a data structure. Properly constructing the data structure for loss of information can help a lot. The example which I know is the Unix file system -- the `data structure' is a normal everyday bi-directionally connected tree in which the leaf nodes (files) can be connected to many interior nodes (directories). If you lose one of the directories you simply lose direct reference to the nodes below that node. Those nodes still reference themselves correctly. And -- I'm not saying that CBM must do it the Unix way. The Unix way isn't the one-true-and-only way that a lot of people think it is. There's a lot of problems with Unix. There's also a *heck* of a lot of *GOOD* ideas there.. -- <- David Herron, an MMDF & WIN/MHS guy, <- Formerly: David Herron -- NonResident E-Mail Hack <- <- Sign me up for one "I survived Jaka's Story" T-shirt!