× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Neil,

Just a guess, but tape is an inherently slower media than disk so your
(time) results actually make sense to me...

SAV = 4.5 Hours
DUP = 6+ hours
RST = 3.25 hours.

The SAV is reading from fast disk and writing to slow tape.  There is a
verify process with each block of data written, so it stands to reason that
it would take longer to SAV where you read from fast disk and write to slow
tape than it takes RST where you read from slow tape and write to fast disk.

During the DUP process you are reading from slow tape and writing to slow
tape.  With all those reads, writes, verifies and tape repositions, it's
just going to take a lot longer.

As to why you were able to put a 13.7GB data set onto a 8GB tape?   Ya got
me.

jte





----- Original Message -----
From: "Neil Palmer" <NeilP@DPSlink.com>
To: <midrange-l@midrange.com>
Sent: Monday, January 14, 2002 7:39 AM
Subject: DUPTAP command


> OK - more a story for comment than a specific question, but I could ask
> why does the DUPTAP command take so bl**dy long ?
>
> Backed up all user data on an old model 400 (CPW 20.6) Friday night, to a
> single 8mm 7/14GB tape (wrote 13.7GB to tape) on an internal 6390 8mm
> drive.  Took just under 4.5 hours to do the complete save.
> Saturday morning went to a model 270 (with CPW 950) to do DUPTAP from 8mm
> to an SLR5-4gb (4/8GB tape) on a 6382 QIC drive, reading from a 7208-342
> 8mm drive.  DUPTAP took just over 6 hours !!  Also, weird thing is we kept
> waiting for message to change QIC tape after about 8GB, but the message
> never came.  It actually wrote all 13.7GB to a single 4/8GB tape (in
> format QIC4DC). ???
> Then back to new model 270 (CPW 150) with a 6386 QIC drive to reload all
> user data. This managed to read the entire tape and restore all the data
> in just under 3.25 hours !
>
> It makes absolutely no sense to me why DUPTAP takes so long to run - even
> longer than to run the actual save or restore jobs on much slower systems
> (although the restricting speed is no doubt the write speed to an SLR5-4GB
> tape, not the CPW of the box).  Anyone else have any annoying experiences,
> or knowledge, on this stupid command ?   ;-)
>
> ...Neil
> _______________________________________________
> This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list
> To post a message email: MIDRANGE-L@midrange.com
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/cgi-bin/listinfo/midrange-l
> or email: MIDRANGE-L-request@midrange.com
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/midrange-l.
>



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.