page@ulowell.UUCP (Bob Page) (01/06/87)
[Note: This article has a lot of things (ideas?) in it. I guess it should have been a few different postings, but they are all related to hard disks, so ... I'm interested in your comments on each. ..Bob] fnf@mcdsun.UUCP (Fred Fish) wrote in article <223@mcdsun.UUCP>: >The $900 was not a typo. Got mine from HT Electronics in Sunnyvale. >Where did you get yours for $750? Direct from CLtd, with the ``developer'' discount that they advertised at the Developer's Conference, along with discounts on the memory board, etc. Some notes about my previous posting (899@ulowell.UUCP): 1. CLtd is preparing a couple of docs on how to use the disk - one for general users, and one for hackers who want to tweak the driver, etc. Word is that they will be available RSN. They recognize that there should have been some mention of it with the hardware... 2. CLtd HAS BUILT a DMA SCSI interface. They did not release it because it was more expensive than the driver that they are selling now, and (most importantly) provided no significant improvement in performance over the non-DMA hard disk. Yes, they did see an improvement reading large files, but for your average application (like icons coming up), there was not much improvement. The bottleneck? AmigaDOS. Tim King (Metacomco) has stated that he has improved the filesystem performance so much that a 400K file that once took 16 seconds to load now takes 3 seconds. When asked how he would make this new format available to all the Amiga users, he said ``through normal CBM/Amiga channels.'' I'm not sure if this means we have to wait for V1.3, or if there will be a mini-release (1.2+ ?) or if CBM will make this a public-domain patch to AmigaDOS (let's hope so). If this new filesystem ever sees the light of day, we'll need a DMA SCSI interface for everyday work. But not now, in the eyes of CLtd. 3. CLtd m i g h t be persuaded to release the source for their disk driver. Call them and ask. They are mostly hardware hackers; software is sort of incidental to them (this is my opinion). 4. I did some performance benchmarks on the drive (even though Fred did some anyway). I ran the benchmark four times, each time under different conditions. I don't have the times right here (look for another posting in a few days about the benchmark program), but essentially the results Fred posted were the best times I got. With fast mem added (I have an old CLtd RAM board w/wait states that I never modified to take them out) the benchmark reports slower times. I think this is the benchmark's problem, but more on that in my posting about the benchmark. The three tests that were the most revealing, however, were the three I did with various versions of ADDBUFFERS. I did one with zero, one with 50, and one with 128 buffers. I run my stiffies with 50 each, and get a great performance boost. [Aside: there should be some way we can determine the optimal number of buffers, based on what we do on each disk ... anybody got an expert system around :-) ] The three results said loud and clear: DON'T USE ADDBUFFERS ON A HARD DISK. It is actually FASTER to search the disk than to search the rambuffer plus the disk. The hit rate is just too low to make it worthwhile. Again, real numbers in a few days, in another posting. Back to Fred: >By the way, I just spent the last 3 days recovering from a scrambled disk. >This could have happened on ANY hard disk, so it's not really a CLtd >comment. Would partitioning the disk have helped any? Can we start a discussion on the nuts and bolts of partitioning disks? Software, I mean. Keep your chainsaws in the shed, thank you. >Was running a program that had several files open on the hard disk and >was actively writing to it when it GURU'd. Bye bye disk structure. Now that more and more people are doing native development on the Amiga, we are seeing a greater need for hard disk support. One nice thing to have would be a back door that could close all open files in case of a catastrophy. Just a hook into the alert code, maybe. Comments? >I did find out that diskdoctor does NOT fix, or even necessarily find, >all filesystem problems. Alas, and disksalv only works on stiffies. Dave H, when you gonna get a hard disk? ;-) >I spent most of new-years day writing my own version of a filesystem >consistency checker, with emphasis on the consistency of the keys. Waiting with baited breath... [what a phrase!] >Bru (Backup and Restore Utility) is a program I wrote for my Unix system >... >I did a quick port to the Amiga about mid-December. The Alpha 1 version >of bru is freely redistributable and will appear on one of my next disks. I'd like the Unix version too! Is it in the mod.sources archives? >So, the question is, have you backed up your hard disk today??? Gulp! >-Fred ..Bob (no connection with CLtd, don'cha know) -- Bob Page, U of Lowell CS Dept. ulowell!page, page@ulowell.CSNET