[Simh] Imaging SCSI HD's

Sun Apr 21 21:19:06 EDT 2019

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 <Mark at infocomm.com 
> <mailto:Mark at 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 at trailing-edge.com <mailto:Simh at trailing-edge.com>
>     http://mailman.trailing-edge.com/mailman/listinfo/simh
> 
> 
> _______________________________________________
> Simh mailing list
> Simh at trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
> 

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol