> On Feb 5, 2017, at 1:33 PM, Johnny Billquist <[email protected]> wrote:
>
> On 2017-02-05 19:21, Paul Koning wrote:
>>
>>> On Feb 5, 2017, at 7:55 AM, Johnny Billquist <[email protected]> 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.
paul
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
