Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!van-bc!root
From: lphillips@lpami.wimsey.bc.ca (Larry Phillips)
Newsgroups: comp.sys.amiga
Subject: Re: MountList entry for Quantum 80 needed
Message-ID: <2403@van-bc.UUCP>
Date: 5 May 89 13:40:17 GMT
Sender: root@van-bc.UUCP
Lines: 90

In <3455@eos.UUCP>, barry@eos.UUCP (Kenn Barry) writes:
> I just got a Quantum 80-meg for my Amiga 1000,
> [...]
> the Quantum docs show that the Quantum has two zones
>on it, with different numbers of sectors/track in each zone, and I
>don't know how to write a MountList entry to accommodate this.

> I imagine I could partition the drive into two logical drives,
>with the dividing line where the number of sectors/track changes, but I
>don't want to do this. I like having one big partition, and I don't
>want to have to reload the whole drive in any case. Can anyone give me
>any hints on a MountList entry?

What you need to do is to figure out the total number of blocks available, and
to make a mountlist that has entries reflecting the total blocks. For example,
let's say a drive has 100,000 blocks. You could use a mountlist that reflects a
drive having 1000 cylinders, 10 heads, 10 blocks per track. You could also
use a mountlist that shows 500 cylinders, 10 heads, and 20 blocks per track. It
makes no difference to the drive, since it is only asked for absolute block
numbers (blocks offset from sector 0). Find the numbers that maximize the
usable data blocks.

I know you don't want to partition the drive, but this seems as good a place as
any to warn folks about a common misunderstanding.

If you partition the drive, you will still have to figure out an overall total
block count, and find the cyl/head/sector numbers that do the trick. The
alternative is to do a lot of calculations. Let's look at an example.

Assume a drive that has only 10 cylinders, 10 heads, with the first 5 cylinders
having 20 blocks/track, and the second 5 cylinders having 10 blocks/track.
Assume further that there are no reserved sectors, and that we can use the
entire disk. We want to partition it at the dividing line.

The first partition is easy. We simply tell it:

	LowCyl = 0
	HighCyl = 4
	Surfaces = 10
	BlocksPerTrack = 20

The second one, though it looks easy, is tricky. One would assume that the
mountlist for the second drive looks like this:

	LowCyl = 5
	HighCyl = 9
	Surfaces = 10
	BlocksPerTrack = 10

The effect of this is to tell Amigados that the _ENTIRE DRIVE_ containing this
partition has the geometry specified in this entry. In fact, this will cause
the first block of the second partition to start at block 501 (5 cyl * 10 heads
* 10 sectors/track). Note that the first partition starts at block 0 and ends
at block 1000. We end up with overlapping partitions, with disastrous
consequences. In this simple (and unrealistic) case, the problems will show up
very soon, since the second partition starts at about the root block of the
first partition. Formatting the second parttition will clobber the first.
Writing any files to the first partition will likely destroy the filesystem
identifier in sector 0 of the second partition.

The second partition can be done, but we have to lie to it in the mountlist:

	LowCyl = 10
	HighCyl = 19
	Surfaces = 10
	BlocksPerTrack = 10

This entry will tell Amigados that the entire drive has a geometry of 10 heads
and 20 sectors/track, and by lying to it about the starting cylinder, we arrive
at the proper starting block (the starting block of the partition is calculated
from the mountlist entry values). Note that everything works out well, and we
get all the blocks available to us.

The main problem with this method is that it usually ends up being a bit of a
brainbender, since most drives don't have numbers that are quite so easy to
calculate.

I have seen a lot of postings recently about making 880K simulated floppies,
and a lot of postings about corrupt partitions. These will go hand in hand
unless the above is taken into account.

-larry

--
  - Don't tell me what kind of a day to have! -
+----------------------------------------------------------------------+ 
|   //   Larry Phillips                                                |
| \X/    lphillips@lpami.wimsey.bc.ca or uunet!van-bc!lpami!lphillips  |
|        COMPUSERVE: 76703,4322                                        |
+----------------------------------------------------------------------+