On 2017-02-05 22:15, Johnny Billquist wrote:
On 2017-02-05 21:31, Mark Pizzolato wrote:
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.
Ouch. Thanks for that bit of information, Mark. A bit ugly, but I can
see that there is no easy solution to the problem.
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.
I can certainly give all the information you need for ODS-1, which is
what RSX use. The structures are pretty similar to ODS-2, so if you
already have that, it should be very simple to add the ODS-1 stuff.
Unfortunately, this will only cover RSX systems. For RT-11 (as well as
RSTS/E and others), you'll have to get someone else to help. I suspect
Paul should know RSTS/E, if he just have the time.
Anyway, the gist in ODS-1 is that the size of the device is contained in
a file called BITMAP.SYS (FID 2,2,0). In there, there is a 32-bit value
saying what the size of the disk is in logical blocks.
The trick is finding BITMAP.SYS, given only the home block, which is the
only known block at the start. The home block (which also happens to be
a part of INDEXF.SYS (FID 1,1,0)) holds a pointer to where the file
header bitmap area is (which is also a part of INDEXF.SYS) and the size
of the file header bitmap. Continguous with this is the first 16 file
headers, and each file header is one block. So, with this information,
you can find the file header for BITMAP.SYS, and from there you get the
size.
Now, I know this is way too fuzzy to actually implement from, but if you
recognize this from ODS-2, then I can just give you the small details
needed to adopt for ODS-1, and you should be set.
Actually, I suspect that the ODS1 spec is not secret anyway, so I
figured I might as well make it publicly available.
http://mim.update.uu.se/ods1
And I'm happy to answer any questions.
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
