Chuck.Phillips@FtCollins.NCR.COM (Chuck.Phillips) (09/09/90)
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? <Don't try this at home, Kids!> 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 <std/disclaimer.h> -- Chuck Phillips MS440 NCR Microelectronics Chuck.Phillips%FtCollins.NCR.com 2001 Danfield Ct. Ft. Collins, CO. 80525 uunet!ncrlnk!ncr-mpd!bach!chuckp
jet@karazm.math.uh.edu (J. Eric Townsend) (09/10/90)
Kent wites:
>Fsck is overdue for AmigaOS.
You mean there isn't one? (I still haven't gotten a hard drive yet,
and I expect floppies to crash regularly.)
Wow. Time for somebody to get to work. (Maybe once I get a hard
drive.)
--
J. Eric Townsend -- University of Houston Dept. of Mathematics (713) 749-2120
Internet: jet@uh.edu
Bitnet: jet@UHOU
Skate UNIX(r)mrush@csuchico.edu (Matt "C P." Rush) (09/12/90)
In-reply-to: CHUCK.PHILLIPS.90Sep9155105@halley.FtCollins.NCR.COM > 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! {Lot's of stuff deleted} > 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. That sort of thing is going to trash a lot of small systems. Unless you've got some kind of power filtering/UPS a powerfailure is going to create some pretty nasty magnetic pulses around that disk drive... > 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? <Don't try this at home, Kids!> On a more practical-experience note: I have. Frequently. The non-shared Write Lock makes that file unaccessable to other/new tasks UNTIL such time as the system is rebooted (and I assume the Disk- Validator does its trick). But the data is usually STILL THERE and the disk is certainly NOT corrupted (as was implied might happen). > 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. "Normal" use? What is "NORMAL" use? :-) I haven't had the power failure, or the novice user problems, but all the other have occured. Yes, I agree that AmigaDOS is not the most reliable File System around, but they all have some drawbacks (just for fun, try deleteing the . or .. dir on a MS-DOG disk :-). My point was strictly to say that beyond the handling of the FLOPPY disks, CBM can NOT be held _completely_ responsible, and that since the Amiga is a SINGLE-USER multitasking system it is up to that single user to take at least a little part in the scheduling of tasks (as it were, wait until AFTER you copy your 300k to your floppy before you issue DIR OPT A :-) Bonus Disclaimer: This is NOT intended to be a flame. Also, our news-reader has been buggering up, so I had to do this follow-up using Pnews. My appologies to any involved/quoted parties that were not correctly identified. -- Matt *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* % "Progress is an up-hill battle % mrush@csuchico.edu % % against backwards compatibility." % mrush@cscihp.UUCP % % -- me % % Now: mrush@cscihp.ecst.csuchico.edu % *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* This is a SCHOOL! Do you think they even CARE about MY opinions?!