[Simh] porting RL01 images to RL02

[Mark Pizzolato]

On Sunday, February 5, 2017 at 11:07 AM, Johnny Billquist wrote:
> On 2017-02-05 19:50, Paul Koning wrote:
> >
> >> On Feb 5, 2017, at 1:33 PM, Johnny Billquist <bqt at softjar.se> wrote:
> >>
> >> On 2017-02-05 19:21, Paul Koning wrote:
> >>>
> >>>> On Feb 5, 2017, at 7:55 AM, Johnny Billquist <bqt at softjar.se> wrote:
> >>>>
> >>>> I'm not entirely clear about what you mean by "porting".
> >>>>
> >>>> Are you talking about getting the files and file system across from one
> >>>> type of device to another? If so, it might depend on the file system in question,
> >>>> but for the ones I can think of, in general, you can just copy the content to a
> >>>> larger device and it works just fine. You will not get access to the extra space
> >>>> though, as the existing file system only knows about the blocks that existed
> >>>> when it was created.
> >>>
> >>> For RSTS, that's often not true, for two reasons.  One is the "cluster size".
> >>> There's the device cluster size and the pack cluster size.  The former is the
> >>> power of two such that device size in blocks divided by that cluster size is <=
> >>> 65536.  The pack cluster size is the file system allocation unit.  It must be >= the
> >>> device cluster size.  If you put a small device file system on a larger device, it
> >>> may have too small a pack cluster size.
> >>>
> >>> The other, more limiting, issue is that the free cluster bitmap (file
> >>> [0,1]satt.sys) must be large enough for the device the file system sits on.  If the
> >>> pack cluster size still works for the device in question (for RL01 vs. RL02 that
> >>> would always be true) you may well have a bitmap file that's too short for the
> >>> larger device.
> >>>
> >>> Both of these issues will cause the OS to complain when you try to mount
> >>> > the file system.
> >>
> >> Paul, I don't know much about the internals of RSTS/E (as you might know).
> >> Are RSTS/E going through these kind of checks on mount? In RSX, various kinds
> >> of parameters are stored in the FS home block, and what is used on all future
> >> mounts, and processing. These structures and data are just assumed to be
> >> inherently consistent, and no check is made against the actual disk drive, to
> >> check if the number of blocks on that device match against these structures.
> >
> > Yes, they actually are checked.  The first one has to be, because file system
> > related I/O is done in terms of device clusters (so the addresses are 16 bits) and
> > since various file system pointers are in units of pack clusters, it needs to
> > calculate pcs/dcs to get the conversion factor.  If that is zero (because pcs <
> > dcs) it complains.
> >
> > There are also validity checks on the storage bitmap file.  It clearly would be
> > straightforward to accept other size bitmaps, but that's not how the code is
> > written.
> 
> Thanks for the information. The RSTS/E code have just had the basic
> information stored in the first block or so, which would then have been used
> to work things out, instead of dynamically figuring thing like cluster size out at
> mount time based on actual device size.
> 
> In RSX, block 0 and block 1 have predefined functionality.
> Block 0 is the boot block (obviously), and block 1 is the home block, which
> holds all the needed information to then access all the other structures and
> data stored on the disk. And if block 1 should be bad, there are backups at
> various other places on the disk, in a scheme that looks very similar to how the
> superblock works in most Unix file systems.
> 
> So a mount consists of reading in the home block, and then set things up based
> on information in there.

A concept related to this discussion is simh's auto sizing of disks.  In the PDP11 and 
VAX simulators the RQ and RP disks use the sim_disk library to perform I/O to disk
Images and/or physical disk devices.  

A relatively new feature that this code performs is that it make an attempt to peek 
into the image file being attached and determine the size of the file system that 
is in the container file.  Currently there is support for detecting the size of ODS2/5
file systems and Ultrix partition tables.

Peeking into the disk structure of these disks is necessary to properly auto size them.
This is necessary since if disk images were created using a simh 3.x simulator, there
was no auto sizing available AND a 3.x disk container only got to be full sized if some
operation in the operating system actually wrote to the end of the disk.  RP disk 
images often got to be full sized when they were initially created when the BAD 144
data was written to the last track when simh created the disk. RQ disk images didn't 
have this.  The simh 4.x code writes to the last simulated sector whenever a disk is 
created, so auto sizing merely based on size works for that case, but VMS and other
OS disk images certainly exist that were created with a 3.x simulator.  Auto sizing is 
the default behavior when RQ and RP disks are attached, so a consistent way to 
determine (and verify) a disk's size must look into the disk's contents.

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.

If anyone wants to take a direct crack at this, I'll be glad to include the results, and 
also add the validation logic to the other disk types that these systems supported 
(RK, RL, etc...).

Alternatively, If someone has precise information about the file system data 
structures and how to walk them to determine the a disk's size, I'll take that.

Thanks.

- Mark