[Info-vax] Alpha SCSI disks won't mount on integrity

[Chris Townley]

On 22/12/2021 16:01, Rich Jordan wrote:
> On Wednesday, December 22, 2021 at 4:59:57 AM UTC-6, Jan-Erik Söderholm wrote:
>> Den 2021-12-22 kl. 04:17, skrev abrsvc:
>>> On Tuesday, December 21, 2021 at 9:54:59 PM UTC-5, Stephen Hoffman wrote:
>>>> On 2021-12-22 02:28:12 +0000, Rich Jordan said:
>>>>
>>>>> I'm trying to set up for a large scale move of data from an Alphaserver
>>>>> to a remote newer Integrity; we need to do a bulk move (at a scheduled
>>>>> time) much faster than the intervening networks will allow. The total
>>>>> transfer will be around 4 terabytes but is able to be stored in
>>>>> savesets (or raw data, TBD) on those 300GB disks...
>>>>
>>>> INIT /ERASE /GPT /SYSTEM /STRUCT=5 [...] the disks on OpenVMS Alpha
>>>> (with adequate max files and headers set, as the INIT defaults are
>>>> ~always bad), re-populate the disk contents, and try the transfer again.
>>>>
>>>> Or just shovel the stuff over onto some SSD-based laptop (zip "-V" with
>>>> current zip 3.0 and unzip 6.0) and transfer that over to the new
>>>> network, as four terabytes of storage is dinky by present-day storage
>>>> standards. Or if the local laptops are as dinky as the OpenVMS Alpha
>>>> data, scrounge an external SSD or HDD and use that for the transfer.
>>>>
>>>>
>>>>
>>>>
>>>> -- 
>>>> Pure Personal Opinion | HoffmanLabs LLC
>>> How about setting up the Itanium system as a cluster node that MSCP serves the target disks. Use shadowing to copy the droves and keep them current until the move?
>> Maybe becuse:
>>
>> "...and we don't have shadow licenses at either end to use that option..."
>>> That way all you really need to move is any system disk data. I used this technique a few times where the target system was not yet ready for production but could keep up with data changes.
>>>
>>> Dan
>>>
> 
> Yep, needless to say no cluster licenses either.
> 
> Hoff, I have a spare disk I can try that with.   We always do the increased headers and files.  If it works that should solve the problems.
> 
> ZIPping takes longer by far than the transfer on a local GbE network but I haven't tried just straight encapsulating ZIPs with no compression.  That may be worth a try.
> 

Have you tried ZIP-ping with a lower compression?

I often used ZIP -3 which gave very slightly less compression but was 
significantly faster



-- 
Chris