[Simh] porting RL01 images to RL02

[Paul Koning]

> On Feb 7, 2017, at 4:28 AM, Mark Pizzolato <Mark at infocomm.com> wrote:
> 
>>>> ...
>> 
>> 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.

Ok.  Looking at the free space bitmap will produce an upper bound, possibly a loose one.  I'd want to pick a valid size for the device in question so the drivers don't freak out.  Are there standard tables of possible sizes for the various devices?  If not then I'll need to add those, for all models other than MSCP where any size is valid.

> 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

It doesn't actually achieve that if the file system supports sparse files, as many Unix systems do.

>         3) it leaves a Simh Format disk at the intended size so it may
>            subsequently be autosized with the correct size.