This is a global command possibly for folks who have configurations which
always explicitly specify the drive type they want a particular unit to be
before they attach a container to the unit. The side effect of this will
be to avoid the addition of drive type describing meta data to disk
containers.
At this time:
- The ZAP command exists to remove meta data from containers that
have it. Container files processed by the ZAP command will generally
be restored to the size it was before the addition of the meta data
and the file time stamps will be unchanged.
- Newly created containers get meta data.
- At attach time, containers that don't have meta data, but have
recognized file systems that fit within the drive it is being
attached to get meta data added without changing the file timestamps.
- Containers that don't have meta data and don't have a recognized
file system that is <= the drive size are attached without comment
and without adding meta data as long as the drive is NOT set to
autosize (controllers that support multiple drive types all default to
autosize, which can explicitly be disabled on a drive by drive basis).
- Containers that don't have meta data which are > the drive size can
only be attached read only.
- Containers with meta data can not be attached to a different
controller at all if the container size is smaller than the drive on the
other controller.
- Containers that have meta data can be freely be attached to the
controller that they were attached to when they got the meta data.
If a file system is detected, it will be reported. Otherwise if no
recognized file system is found, the attach will be silent. File
system detection reporting can be suppressed with -Q on the attach
command.
- Containers with meta data can only be attached read only to a different
controller if the container is larger than the drive it is being
attached to.
In the future:
- In general, containers with meta data (or recognized file systems)
will be attachable to MSCP and SCSI controllers, as long as reasonable
sector sizes and file system not requiring interleaving have been found.
- Containers without meta data will only be attachable if autosize
is disabled and the container is <= the size of the drive.
- Explicitly setting a drive type on a unit will implicitly disable
autosizing. If a user wants to set the default drive for a unit
and still allow autosizing they must explicitly set the unit to
autosize after setting the drive type.
Relevant to: #1065, #1059, #1094, #1100, #1118, #1117
Historically this functionality was reimplemented within each
DEVICE simulator often with slightly different implementations
and inconsistencies. Solving this globally within SCP required
changes in many places, but should henceforth be reasonably
managed.
As discussed in #1034
- Make all PDP11, VAX RP and RQ devices autosizing behave similarly
- Generalize the attach help to be specific to the device/system being
attached
- Remove the sim_disk_pdp10_* calls which weren't correct or needed
since sim_disk_attach_ex provides sector size which is used correctly
The sim_disk_pdp10_... API's specifically provide 1024 byte sector
interfaces for 64bit data.
Customize the attach help output to be more appropriate for the devices
in the running simulator and the device who's help is being displayed.
This allows the underlying disk container formats that that sim_disk supports
(VHD, SIMH or RAW) to be accessed from the PDP10 KS10 simulator, and later
on to Rich Cornwell's PDP10-KA, PDP10-KI, and PDP10-KL simulators.
BAD144 info was written correctly if the user answered Y when the disk
image was created, but would not work if SET RPn BADBLOCK was
entered later.
Auto sizing would be potentially wrong if a disk had been created
without writing the BAD144 data. Now, if the disk contains a file system
that information along with the physical container's size is used to
properly auto size the disk.
These changes facilitate more robust parameter type checking and helps
to identify unexpected coding errors.
Most simulators can now also be compiled with a C++ compiler without
warnings.
Additionally, these changes have also been configured to facilitate easier
backporting of simulator and device simulation modules to run under the
simh v3.9+ SCP framework.
I’ve always wanted to have the option to have simulated devices behave
more naturally with respect to I/O operations. By more naturally I
mean that the current simulator model I/O is either polled (for asynchronous
things link Muxes and Network), or it is performed in the middle of some
instruction execution taking possibly many milliseconds (disk and/or tapes).
The existing model creates quite deterministic behavior which helps to debug
and understand issues, but it trades off potential instruction execution
while performing these I/O operations in between instruction execution.
To address this concept (while still retaining the potential advantages of
the original model), I’ve designed an Asynch I/O model extension for simh.
In order to flesh-out and debug this design, I’ve also refactored several
devices to utilize this capability. Please read the attached
0readmeAsynchIO.txt file for concept details about the approach.
In order to make disk devices easy to implement (within or without the
AsynchIO framework), I’ve created a sim_disk.c library which is modeled
on the sim_tape.c library to generalize disk I/O like tape I/O is
generalized in sim_tape.c. This sim_disk.c library now provides that
natural place to implement support for various disk implementation formats
(just like sim_tape support several formats, and one day will be the place
to add direct physical tape access). The current sim_disk library provides
the framework for direct support of 3 different disk formats:
1) standard simh disk format
2) platform specific physical disk access
and 3) platform independent Virtual Disk format.
The Virtual Disk format is an implementation of the format described in
the ”Microsoft Virtual Hard Disk (VHD) Image Format Specification”. The
VHD specification is available for anyone to implement under the "Microsoft
Open Specification Promise" described at
http://www.microsoft.com/interop/osp/default.mspx.
The VHD implementation includes support for:
1) Fixed sized disks
2) Dynamically expanding disks
and 3) Differencing Disks.
Dynamically expanding disks don’t change their “Virtual Size”, but they
don’t consume disk space on the containing storage until the virtual
sectors in the disk are actually written to (i.e. an RA81 or RA92 VHD
with a VMS installed on it may initially only contain 30+ MB of files,
and the resulting VHD will be 30+ MB). The VHD format contains meta data
which describes the virtual device. Amongst this meta data is the simh
device type which the VHD was originally created as. This metadata is
therefore available whenever that VHD is attached to an emulated disk
device in the future so the device type & size can be automatically be
configured.
Sim_disk_attach is used by device emulations to attach a simh/vhd/raw
device to a simulated device. The following simh command switches
are used by the sim_disk_attach API:
-R Attach Read Only.
-E Must Exist (if not specified an attempt to create the
indicated virtual disk will be attempted).
-F Open the indicated disk container in a specific format
(default is to autodetect VHD defaulting to simh if the
indicated container is not a VHD).
-X When creating a VHD, create a fixed sized VHD (vs a
Dynamically expanding one).
-C Create a VHD and copy its contents from another disk
(simh, VHD, or RAW format).
-D Create a Differencing VHD (relative to an already
existing VHD disk)
Examples:
sim> show rq
RQ, address=20001468-2000146B*, no vector, 4 units
RQ0, 159MB, not attached, write enabled, RD54, autosize, SIMH format
RQ1, 159MB, not attached, write enabled, RD54, autosize, SIMH format
RQ2, 159MB, not attached, write enabled, RD54, autosize, SIMH format
RQ3, 409KB, not attached, write enabled, RX50, autosize, SIMH format
sim> atta rq0 RA81.vhd
sim> show rq0
RQ0, 456MB, attached to RA81.vhd, write enabled, RA81, autosize, VHD format
sim> set rq2 ra92
sim> att rq2 -f vhd RA92.vhd
RQ2: creating new file
sim> sho rq2
RQ2, 1505MB, attached to RA92.vhd, write enabled, RA92, autosize, VHD format
sim> ! dir RA92.vhd
Volume in drive H is New Volume
Volume Serial Number is F8DE-510C
Directory of H:\Data
04/14/2011 12:57 PM 5,120 RA92.vhd
1 File(s) 5,120 bytes
0 Dir(s) 3,074,412,544 bytes free
sim> atta rq3 -c RA92-1.vhd RA92.vhd
sim> atta rq3 -c RA92-1.vhd RA92.vhd
RQ3: creating new virtual disk 'RA92-1.vhd'
RQ3: Copied 1505MB. 99% complete.
RQ3: Copied 1505MB. Done.
sim> sh rq3
RQ3, 1505MB, attached to RA92-1.vhd, write enabled, RA92, autosize, VHD format
sim> ! dir RA92*
Volume in drive H is New Volume
Volume Serial Number is F8DE-510C
Directory of H:\Data
04/14/2011 01:12 PM 5,120 RA92-1.vhd
04/14/2011 12:58 PM 5,120 RA92.vhd
2 File(s) 10,240 bytes
0 Dir(s) 3,074,404,352 bytes free
sim> sho rq2
RQ2, 1505MB, not attached, write enabled, RA92, autosize, VHD format
sim> set rq2 ra81
sim> set rq2 noauto
sim> sho rq2
RQ2, 456MB, not attached, write enabled, RA81, noautosize, VHD format
sim> set rq2 format=simh
sim> sho rq2
RQ2, 456MB, not attached, write enabled, RA81, noautosize, SIMH format
sim> atta rq2 -c RA81-Copy.vhd VMS055.dsk
RQ2: creating new virtual disk 'RA81-Copy.vhd'
RQ2: Copied 456MB. 99% complete.
RQ2: Copied 456MB. Done.
sim> sho rq2
RQ2, 456MB, attached to RA81-Copy.vhd, write enabled, RA81, noautosize, VHD format
sim> det rq2
sim> ! dir RA81-Copy.vhd
Volume in drive H is New Volume
Volume Serial Number is F8DE-510C
Directory of H:\Data
04/14/2011 01:22 PM 178,304,512 RA81-Copy.vhd
1 File(s) 178,304,512 bytes
0 Dir(s) 2,896,097,280 bytes free
sim> ! dir VMS055.dsk
Volume in drive H is New Volume
Volume Serial Number is F8DE-510C
Directory of H:\Data
03/08/2011 01:42 PM 403,663,872 VMS055.dsk
1 File(s) 403,663,872 bytes
0 Dir(s) 2,896,097,280 bytes free
sim>
