Not sure there is any meaning to setting the block size for the output
to stdout. It goes to a pipe, and no hardware, so DMA limits do not apply.
From the pipe it then goes to ssh, so we're in the end talking about
data over a tcp connection, so no hardware affects things there either
(not to mention that ssh is just reading the data from the pipe as
well). So the only restriction I can think of would be if there is an
upper limit to the write to a pipe in general. Not sure about that
one... The "network block size" comment makes no sense. ssh probably
just runs the data through, so we're just pouring data into tcp, which
chops things into segments according to its own ideas anyway, and
whatever block size you said to dd have already been lost at the pipe.
On the other hand, it most likely also have essentially no bad effects
setting the block size either. In the end, we end up with a stream of
bytes, and dd at either end aggregates.
Johnny
On 2019-04-22 02:52, Clem Cole wrote:
I love Mark's solution in the theory, but the systems I have that
continue to have solid SCSI support don't have a copy of simh, nor
enough local disk for the output. What I have done in the past is
something on the order of:
dd if=/dev/RSCSI_DISK ibs=VERY_LARGE obs=4k conv=sync | ssh remote_sys
dd of=/tmp/vdisk.dsk ibs=4k obs=VERY_LARGE
The reason for the obs=4kis to keep the network block size under
control. Depending on source and destination. Blocking then becomes
what is right for the system (on something like a Vax or early x86 based
bus maps, they can only do 64K bytes of DMA at a time even if the host
has more memory, so even if you put a larger block, it's not clear you
will get much more speed up, and the OS how to clear our memory for the
I/O, so it becomes a trade off -- i.e. YMMV)
Now I have a/couple of different version(s) of dd I dug up/rewrote years
ago called ddd - double dd (before gnu's Debugger existed BTW). The
original ddd used to UNIX processes the swap back and forth controlled
via a pipe (you can find it in the UUNET archives I want to say around
1985), but my newer versions used can use threads of some sort if the
local UNIX supports MxN user mode threading, or async I/O is that was
supported as the threading overlap tends to be more efficient in the
kernel itself, but the idea is the same - you want as much I/O
overlapped as possible. [I originally did this to fully stream tape
drives in the bad old days of a 10Mhz 68000 are the processor. We ran:
dump -f - | ddd of=/dev/rmt0 ibs=20b obs=64k].
ᐧ
On Sun, Apr 21, 2019 at 5:37 PM Mark Pizzolato <m...@infocomm.com
<mailto:m...@infocomm.com>> wrote:
On Sunday, April 21, 2019 at 11:28 AM, Zane Healy wrote:
> I have a DL380 on the way to add to my ESXI cluster here at
home. As a result
> I’m looking to finish virtualizing my DEC HW. What is the best
way to convert
> a physical SCSI HD to a disk image for SIMH? I need to do this
for both VAX
> and PDP-11.
If these are SCSI disks, AND you have a host system with a SCSI host
adapter
that can connect to these disks (i.e. it is the correct SCSI width,
and type),
then you can do this directly using simh from the host system.
Warning: If you try to do this under some complicated set of layered
virtual systems, then you are on your own (recall your VNC experience).
Depending on your host system the OS will have some name for the
above mentioned SCSI disk(s) which you've connected.
When you connect these disks to the host system, BE SURE not to
perform any action on these drives BEFORE you let simh see them.
Be sure you identify the raw device name that the OS sees the newly
connected SCSI disks as. Knowing that name the following should work
with a VAX or PDP11 simulator. Note that this will probably have to
be done as root in order to access the physical devices.
# vax
sim> ATTACH RQ0 -c <rawdevicename> disk1.vhd
sim> DETACH RQ0
This will produce a "disk1.vhd" container file with all of the bits
that can be read from the original SCSI disk.
Repeat as necessary for each original disk.
> One of the main systems that I want to Virtualize is a VAXstation
4000/60
> with a BA350 shelf. The only HD connected to the system is a
RZ28-VA SBB
> (2GB) as DKA200:, so yesterday I added a RZ29-VA SBB (4GB) as
DKA100:. I
> setup Standalone Backup on the RZ29 and booted into Standalone
backup.
>
> I tried to run the following:
> backup/image/verify dka200: dka100:[000000]20190420-system.sav/sav
>
> I ended up with a very strange “No valid storage bitmap found”
error, and it
> failed to copy anything.
>
> Facility: BACKUP, Backup Utility
> Explanation: Software bad block data is not present on the
volume. The
> volume has been initialized with no bad blocks.
> User Action: Execute the Bad Block Locator utility before using
the volume.
> NOBITMAP, no valid storage bitmap found on 'device-name’
>
> I tried ANALYZE/MEDIA, but may not have been doing things right.
This is a
> Genuine RZ29-VA, but it was originally used as part of a disk
array for a Sun
> Sparc system.
This exercise will merely put a backup saveset on another disk which
I don't
see getting you very far towards making it accessible from simh.
Meanwhile, I suspect you are seeing a failure under standalone
backup due
to the fact that after you added the DKA100 disk drive to the system
you
didn't initialize the disk. You can't initialize a target disk
under standalone
backup, so you'll have to do that with full VMS running before you
attempt
the backup again.
- Mark
_______________________________________________
Simh mailing list
Simh@trailing-edge.com <mailto:Simh@trailing-edge.com>
http://mailman.trailing-edge.com/mailman/listinfo/simh
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
