[Simh] porting RL01 images to RL02

[Johnny Billquist]

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.

	Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol