[Simh] porting RL01 images to RL02

[Mark Pizzolato]

On Monday, February 6, 2017 at 1:11 PM, Paul Koning wrote:
> > On Feb 5, 2017, at 6:25 PM, Paul Koning <paulkoning at comcast.net> wrote:
> >
> >
> >> On Feb 5, 2017, at 3:31 PM, Mark Pizzolato <Mark at infocomm.com> wrote:
> >>
> >> ...
> >>
> >> So, I'd like to expand the set of file system types that the auto
> >> sizing logic can perform to include RSTS disks and whatever might be
> >> commonly used with RSX and RT11.
> 
> A possible complication with RSTS: I can't find the precise device size because
> that isn't stored anywhere in the file structure.  What I can find is the size
> rounded up to the next multiple of 4096 times the cluster size (from the free
> space bitmap size in blocks, since each bit represents a free cluster).  I can also
> find a lower bound, from the end of the last free cluster in the bitmap.  But if
> some of the space at the end of the pack is in use -- not all that common but
> certainly possible -- then that doesn't help.

Well, what you can do would actually be fine.  If the disk size was limited to 
the furthest place user program data could be written in the file system, then 
the problem would be solved.  If someone using a 3.x simh version actually wrote 
beyond that, then the size would already be reflected in the container's size
which would then be larger.  The problem this is really solving is the one when 
we were limited to determining the size of the disk by the size of the container 
which might not have been completely written to.

If auto sizing restricted the disk to be the largest space the file system describes,
then no useful activities would write beyond there and the exact disk model 
wouldn't be important.  Right?  This whole activity is to support correct simulator 
behavior when using a disk container created with a 3.x simulator.   All RP and RQ 
disks created with the 4.x code will write the first and the last blocks in a newly 
created disk.  The comments around the code that does this says:

       On a newly created disk, we write a zero sector to the last and the
       first sectors.  This serves 3 purposes:
         1) it avoids strange allocation delays writing newly allocated
            storage at the end of the disk during simulator operation
         2) it allocates storage for the whole disk at creation time to
            avoid strange failures which may happen during simulator execution
            if the containing disk is full
         3) it leaves a Simh Format disk at the intended size so it may
            subsequently be autosized with the correct size.

- Mark