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 Fisk
 wrote 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."