<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">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:</div><div class=""><br class=""></div><div class=""><span style="color: rgb(34, 34, 34); font-size: 15px; font-variant-ligatures: normal; orphans: 2; widows: 2;" class="">dd if=/dev/sda0 ibs=512 obs=512 of=/tmp/vax_image.dsk</span></div><div class=""><br class=""></div><div class=""><span style="color: rgb(34, 34, 34); font-size: 15px; font-variant-ligatures: normal; orphans: 2; widows: 2;" class="">Zane</span></div><div class=""><span style="color: rgb(34, 34, 34); font-family: 'Helvetica Neue', Arial, sans-serif; font-size: 15px; font-variant-ligatures: normal; orphans: 2; widows: 2;" class=""><br class=""></span></div><div class=""><span style="color: rgb(34, 34, 34); font-family: 'Helvetica Neue', Arial, sans-serif; font-size: 15px; font-variant-ligatures: normal; orphans: 2; widows: 2;" class=""><br class=""></span></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Apr 21, 2019, at 5:52 PM, Clem Cole <<a href="mailto:clemc@ccc.com" class="">clemc@ccc.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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:</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""></div><div class="gmail_default" style=""><font face="arial, helvetica, sans-serif" class=""> </font><font color="#0000ff" style="" face="monospace, monospace" class="">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</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""></div><div class="gmail_default" style=""><span style="font-family:arial,helvetica,sans-serif" class="">The reason for the </span><font face="monospace, monospace" color="#0000ff" class="">obs=4k</font><font face="arial, helvetica, sans-serif" class=""> 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)</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""></div><div class="gmail_default" style=""><font face="arial, helvetica, sans-serif" class="">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: </font><font color="#0000ff" style="" face="monospace, monospace" class="">dump -f - | ddd of=/dev/rmt0 ibs=20b obs=64k</font><font face="arial, helvetica, sans-serif" class=""> ].</font></div></div></div></blockquote></div></div></body></html>