[Simh] porting RL01 images to RL02

[Mark Pizzolato]

On Tuesday, February 7, 2017 at 6:38 AM, Paul Koning wrote:
> > 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.

That problem is handled in each of the device simulators which both 1) do auto 
sizing and 2) know about the set of possible disk types/sizes that the device 
controller supports.

The question that needs answering is:  Does this disk image contain a recognized 
file system, and, if so, how big is that file system.  An additional nicety would be 
to display the volume label if that is a meaningful detail in the file system being 
recognized.

> > 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.

OK.  I'll change it to write the whole file with zeros.

- Mark