On 2017-02-05 19:50, Paul Koning wrote:
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.
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: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
[email protected]
http://mailman.trailing-edge.com/mailman/listinfo/simh
