× 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.



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

default compression. our 8mm does 1 tape for approx 15 gig

jim franz


----- Original Message -----
From: "John Earl" <johnearl@powertechgroup.com>
To: <midrange-l@midrange.com>
Sent: Tuesday, January 15, 2002 1:49 AM
Subject: Re: DUPTAP command


> 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.
> >
>
> _______________________________________________
> 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 ...

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.