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 <[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.
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 _______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
