Path: utzoo!utgpu!attcan!uunet!tektronix!ozvax!randyh From: randyh@ozvax.GWD.TEK.COM (Randy Hendry) Newsgroups: comp.sys.amiga.tech Subject: Re: jh1 (bridgeboard harddisk problems) Keywords: jh1 djmount bridgeboard dpformat Message-ID: <896@ozvax.GWD.TEK.COM> Date: 15 Aug 88 21:42:51 GMT References: <880@ozvax.GWD.TEK.COM> Reply-To: randyh@ozvax.UUCP (Randy Hendry) Organization: Tektronix, Inc., Wilsonville, OR. Lines: 92 The saga continues... I wrote: >Why does djmount no longer recognize my second hard disk partition? I seemed to have answered this one myself (at least partially). (If you remember, some part of the OS was refusing to recognize jh1: as a hard disk partition.) The problem seems to be related to me making the partition *too small*. I had made it only 5 cylinders (~0.25MB) for testing when I got the strange failure. When I increased it up to 2MB (~40 cylinders) djmount, et al. worked fine again. My conclusion is that there is some lower limit for a disk partition size that I exceeded. Anyway, onward... (i.e., now I'm back to the original problem:) >"dpformat drive jh1: name jh1"; >Format cyl 516. Retry required cylinder 1. Hard error cylinder 1. Brian Rhodefer (brianr@tekig4.TEK.COM) suggested that I try DiskDoctor on the sick partition. Good idea; I did. When I ran DiskDoctor it, started reporting: (paraphrased) Hard Error Track 1 Surface 6. ... Hard Error Track 1 Surface 10. Hard Error Track 2 Surface 6. ... And did so for every track (cylinder) of the disk (until I stopped it that is). There is a good reason for this: There are no heads (surfaces) 6-10 on this disk! The disk has 6 heads (0-5). Now non-coincidentally :-( the disk on which partition jh0: resides *does* have 11 heads (0-10). It appears that djmount (or dpformat) is using the head information for the first drive for all drives. BTW, I thought I might have things hooked up wrong, but MS-DOS doesn't have a problem with the drives and also David Fiskwrote to me saying that he was having the exact same problem and even came to same conclusion about djmount(?) assuming the wrong number of heads. Seeing this error made me think that I might be able to tell djmount manually about the number of heads by using MountList. I tried a couple of combinations, but had no luck. Djmount doesn't seem to use MountList -- is this true? So now, assuming my problem is truly with the number of heads, 1. What do I do to get Janus to know about the difference in the drives? 2. If it is with djmount, how do I tell djmount that the second drive only has 6 heads? 3. If it is MountList I should use, what are all the magic numbers? (specifically the unit number and cylinder numbers (i.e. do I start with 0 since the partitioning is done on the MS-DOS side, or do I use the actual physical cylinder numbers))? 4. (This is more out of curiosity and to show my lack of understanding of all the goings on with the bridgeboard): why doesn't Janus just use mount and format like the other disk drivers (especially since one can mention the driver to be used in the MountList)? Again, all insights or comments are appreciated. Now on to other comments prompted by my initial posting... Andy Finkel (andy@cbmvax.UUCP) writes: >AmigaDOS V1.2 only supports about 54meg per partition in V1.2. >This limit is removed under 1.3, using the FastFileSystem. Thanks for the tip. This size limit (along with whatever the minimum is) should be mentioned in the user's guide for the bridgeboard. Also, I seem to remember someone saying that Janus wouldn't support the FFS. Has that changed, or is it just currently true (i.e. before the official 1.3 release)? >Actually, it [dpformat] uses the exact same bad track method that is used >on the PC side for all of its XT hard disks. Good. That's what I thought I saw happening. I don't know if I'm on track here since I haven't been able to play much at this level yet, but I was guessing that Brian Rhodefer's (brianr@tekig4.TEK.COM) formatting problem might be that there were bad spots in addition to the ones on the manufacturer's flaw map and that Janus was pickier about it's disk surface than MS-DOS (at least during formatting). I would hope re-*lowlevel* formatting (not dpformat) with the errors given by DiskDoctor would take care of this. BTW, Peter da Silva (peter@sugar.uu.net) writes: >My assertion (which has been blasted again and again in this forum) is that >when the file system gets a bad block, it should mark it as unusable. I agree. But, let me do it manually. E.g. Requestor says, "Block ??? appears to be bad. Would you like to lock it out so the file system will no longer use it?" Me, "Yes." -- Randy Hendry randyh@ozvax.gwd.tek.com ...!tektronix!ozvax!randyh Tektronix, Inc. Graphic Terminals Division (503)685-3063w P.O. Box 1000, M.S. 63-523, Wilsonville, OR 97070 (503)639-7697h "In Oregon, the sun shines every day; in the summer, you can even see it."