On 2016-03-09 17:12, Paul Koning wrote:
On Mar 9, 2016, at 10:55 AM, Johnny Billquist <b...@softjar.se> wrote:
On 2016-03-09 16:50, hb wrote:
On 03/09/2016 09:53 AM, Johnny Billquist wrote:
Do VMS and ODS-2 really try to figure out a geometry per disk for MSCP
disks???
The ODS2 utility needs to "mount" the disk. I know nothing, but ODS-2 on
VMS probably only cares about LBNs and VBNs (and on on-disk data
structures). It is the mount utility which knows or needs to know the
geometry, to do the geometry based search for alternate home blocks
(there is also a non-geometry based search algorithm). And the mount
utility probably uses the same code as the init utility, which writes
the alternate home blocks. And both probably request the information
from some other (driver) code level.
Right. But I would have assumed that VMS would just create some fake concept of
what the geometry is for an MSCP disk, since it don't really make sense to try
and figure out the geometry in the first place. Or at least that is my
understanding.
There is no guarantee that there even is any "sane" geometry.
I long ago forgot the details, but a look at the MSCP Basic Functions manual
(on Bitsavers in the uda50 directory) is helpful. See page 4-25 and the next
couple.
Yes, the basic addressing is LBA addressing. Some early MSCP drives exposed
bad sector handling to the host at least with the UDA, and I remember the large
amount of work that had to be done in RSTS for this. Soon that was moved into
the controllers.
Yes, some controllers require the host to be involved in the bad block
replacement process. But the blocks are still addressed just as LBNs. No
proper exposure to the geometry... Well, it's complicated by the fact
that there are primary and secondary replacement blocks, and the primary
replacement block is on the same track, which means when you want to
find a block to use as replacement, you need to find out if the primary
is unallocated or not. But apart from that RBNs are numbered
sequentially, just like the normal blocks. And you don't properly care
about geometry as such.
Anyway, that section (starting at page 4-27) describes mapping the LBA into 4 values:
sector, track, group, and cylinder -- as a way to expose the performance aspects. It
says that the Get Unit Status command fetches that data. it also says (page 4-28) that
"this is a model for logical geometry, which may have only a tenuous relationship
with the disks's actual physical geometry" and that it's up to the designer to
report a logical geometry that is useful to the host. The idea is that it should let the
host make performance optimization choices, as described in that section.
Thanks for reminding me. Yes, MSCP can give you a geometry information
for the disk. Note that the information might not reflect reality. The
controller and disk is free to lie or make things up, if it thinks it is
better.
However, you should always get the same values for the same hardware.
And, this is where it gets tricky, I would expect VMS to actually figure
out the replacement home block locations based on the geometry reported
by the MSCP controller, which means that what Timothy Litt really wants
is this information, and not the actual disk geometry.
And yes, some aspects of newer drives aren't handled well at all -- for
example, drives with varying number of sectors per track as you move from outer
to inner cylinders. When MSCP was designed I don't think those existed (at
least not in DEC; CDC did it way back in the early 1960s on the 6603 drive).
The first time I heard of variable sector counts at DEC was in CDROMs.
It appears pretty clear in the UDA50 documentation that DEC did
provision for the possibility in MSCP, even if no disks they made at
that point had this property.
So as far as the question here is concerned, it sounds like ODS2 would base its placement on the
"logical" geometry reported by MSCP, and for a standalone ODS2 utility to get that right
would require it to have a table of geometries matching what MSCP controllers reported. And for
that matter, for SimH device formatting to be compatible with that of the real hardware, the
geometries reported in SimH would need to match the originals. I assume the tables in pdp11_rq.c
are based on the original numbers, but I can't confirm that. I never ran into any of this; RSTS
was quite happy with LBA addressing and left "logical geometry" as an entertaining
concept it could completely ignore.
Right. Totally in agreement.
And, as touched on before, RSX do not care about geometry either.
Johnny
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
