Thanks for jogging my mind, it’s been a long time since I’ve done something like this. I should be able to come up with larger SCSI drives in each of these cases.
This thread has also got me thinking, and I need to try and find my notes for how I was imaging RL01 and RL02 disk packs on my VAXen 20+ years ago (for use in SIMH). I was doing that under VMS, probably 5.5-2 or 7.2, and able to go both to and from a disk pack. I’m pretty sure I’ve posted the procedure for the disk packs, but can’t find it online. The real joke is I’ve apparently done this in the past with SCSI drives and dd, as I found a message from me, 14 years ago, advising someone to do something like the following: dd if=/dev/sda0 ibs=512 obs=512 of=/tmp/vax_image.dsk Zane > On Apr 21, 2019, at 5:52 PM, Clem Cole <cl...@ccc.com> 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=4k is 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 ].
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
