[Simh] Disk info request

Johnny Billquist bqt at softjar.se
Wed Mar 9 12:48:43 EST 2016


On 2016-03-09 17:12, Paul Koning wrote:
>
>> On Mar 9, 2016, at 10:55 AM, Johnny Billquist <bqt at 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



More information about the Simh mailing list