Path: utzoo!attcan!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ncrlnk!ncr-mpd!Chuck.Phillips From: Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) Newsgroups: comp.sys.amiga.hardware Subject: fsck WAS: Obsessive Multitasking and Amiga File I/O Scheduling (long) Message-ID: Date: 9 Sep 90 14:51:05 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> Sender: uucp@ncr-mpd.FtCollins Organization: NCR Microelectronics, Ft. Collins, CO Lines: 124 In-reply-to: mrush@csuchico.edu's message of 8 Sep 90 21:05:59 GMT DISCLAIMER: Included are some file system experiments. They are supplied for entertainment value only. Neither I nor my employer can take responsibility for the results. Performing either **PROBABLY WILL** trash your disk. YOU'VE BEEN WARNED! Matt> In article <1990Sep8.050725.14384@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: Kent> I bought my first Amiga, and this latest one, to *multitask*, and I Kent> spend lots of days like the above. Hear, hear! >>>>> On 8 Sep 90 21:05:59 GMT, mrush@csuchico.edu (Matt "C P." Rush) said: Matt> Multitasking was EXACTLY the reason I bought my first Amiga, and I Matt> haven't had that much trouble thrashing disks. Depends on _what_ tasks you run concurrently. Many programs spend the majority of their time _entirely in memory_, and many do not. Matt> Sure, if you have multiple tasks that are accessing different Matt> cylinders on the same floppy there's going to be some head movement. 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. Matt> But that's why Amiga floppies have that extra little circuit board Matt> that PC floppies don't have -- so the drives can be individually Matt> controlled! I've not observed both my floppies doing _simultaneous_ I/O. (Both lights might be on, but only _one_ is actually active at a time. Try anyone's DiskCopy and listen to your drives.) Of course, maybe it's just that none of the disk/file copy programs I use make use of double-buffering multiple processes. Certainly, AmigaOS can support this, but I've never observed it. Is there an exception out there? Matt> If you don't wanna bang your heads around, get a second (or third, or Matt> fourth) floppy. ...or a second (or third, or fourth) hard disk, etc. (What do you mean I don't have any money? I still have checks! :-) Matt> On the occasions where I know I'm going to be doing a lot of disk Matt> thrashing I use the ol' AddBuffers command. That's what it's there Matt> for! 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. Kent>Along with the deadly repeated "key error, backup, reformat and reload" Kent>problems reported here so often, this is another market killer for the Kent>business marketplace (which surely won't tolerate the unreliable hard Kent>disk problem like a crowd of hackers/students ready to do the "repairs" Kent>themselves will), and both need fixes Really Soon. Kent>Buying a machine that advertises multitasking, and then hearing your Kent>disk drive attempt to self destruct when you try to do so is almost Kent>as unimpressive as having your _whole_ file system go gaga and need a Kent>long, frustrating recovery to be done, every time a program dies in Kent>mid-write. Fsck is overdue for AmigaOS. Right on! Matt> I don't think CBM can be held responsible for Hard Disks that get Matt> trashed because of programs failing during Writing. This is more the Matt> responsibility of the companies that manufacture the Hard Drive Matt> controllers and associated drivers. 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. Matt> My current hard drive on my A2000 has never gotten trashed in over Matt> three years -- even if I try! 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? Of course, neither of these would _ever_ happen during normal use, unless there is a power failure, a program crashes or your machine GURUs. ;^) Other contributing causes: Running a program before it's debugged, using PD software, allowing a novice anywhere near your machine, interrupting a running program, rebooting or turning off your machine (just because you _think_ no processes have open files), etc. I _believe_, these problems are out of the control of the controller hardware/software. If I'm wrong on this, someone please correct me. Matt> ... It is a problem of PC developers using PC techniques on the Matt> Amiga, in total disregard of everything that CBM has warned against Matt> since the 1.0 RKM's. ...combined with the fact that _real machines crash_ while programs are running. _Real programs bomb_ (or are killed), sometimes without even the _possibility_ of cleaning up after themselves. I'm not trying to bash C=; they're to be congratulated for their continuing efforts and successes in improving AmigaOS. But... 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? #include -- Chuck Phillips MS440 NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com 2001 Danfield Ct. Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp