[Veritas-bu] RE: [Veritas -bu] Tape Drive speed

2003-07-06 22:16:40
Subject: [Veritas-bu] RE: [Veritas -bu] Tape Drive speed
From: ChuH AT SEC DOT GOV (Chu, Hong)
Date: Sun, 6 Jul 2003 22:16:40 -0400

I agree with Johnny.  We have a Win2k server with 25 million files and 800GB
of space.  The space is not the issue here, rather the large number of files
and limitation of Windows.  We found that it was useful to turn off "perform
backu by archival bit" and use the last modified time for differential
incrementals.  Like Johnny, we are use 9940B and on Unix media server we hit
closely to 15MB/s while on NT only get disappointing average of 2MB/S.  Even
though we try to stagger the policy starting times and have each of the
policy to utilize all the drives multi-streaming, we don't see any better
through put.  Only thing that saved us from able to perform full back up
during the weekend on the NT server with 25 million files, was to
multi-stream the jobs that backs up relatively same # of files and utilize
the exclude and include lists.  Before we were using the "all_local_drives"
file directives and the backup used to take over 36 hours to complete, now
after the creating the exclude and include lists and mutli-streaming groups
of jobs with relatively even number of files for each of the jobs, we can
backup this server just over 24 hours - shaved off 12 hours.  I hope I don't
see another Window server with so much files again.... what a administrative

-----Original Message-----
From: Johnny Oestergaard [mailto:joe AT spamcop DOT net]
Sent: Sunday, July 06, 2003 1:04 PM
To: veritas-bu AT mailman.eng.auburn DOT edu
Cc: veritas-bu AT jasons DOT us
Subject: Re: [Veritas-bu] Tape Drive speed

Not that I have ever used SDLT drives, but I agree that getting max drive 
performance out of any system is difficult (except in a lab where you have 
control of every single bit)

Most tapedrives today are fast. In our installation we use STK 9940B and 
they write data at 30MB/s (before compression) and they easyly do 70MB/s in 
a lab (but not in real world windows installations)

Our installation is pure Windows and all our havy servers are sitting on 
1Gbps on a BlackDiamond 6808, but we hardly see more then 15 MB/s. Our 
biggest performance problem today is that windows is much too slow in 
open/close operation of files. Backup of 2.000.000 files each less then 
16Kbyte takes forever.

By the way start/stop is very fast on the STK 9940B drives and we hardly 
see any tape errors at all. Shoe-shining is not a big problem for us. When 
we used DLT tape problems was a daily thing.

We use FC connections to our drives, but I would expect that you have to be 
carefull about how many drives you connect to each SCSI cntl. Pushing a lot 
of data over a SCSI cntl. is not always the fastest thing in the world.

You should look into blksize, buffers, multiplexing and your network.


At 18:28 02-07-2003 -0400, veritas-bu AT jasons DOT us wrote:
>On Tue, 1 Jul 2003, Mike M. wrote:
> > Hi
> >
> > My system is a AIX machine running Veritas DC 4.5 and the robot use SDLT
> > Drive. The connection between the server and the drive is
> > scsi-controller.
> >
> > When I backup some files from Veritas Server he obtain a data transfers
> > from 8 Mbytes/sec. But the SDLT Drive should accept until 11 Mbytes/sec!
>SDLT drives are rated at 11mB/sec without compression and, in theory will
>do 22mB/sec if you have *very* compressable data.  That said, you will
>very rarely see those speeds with SDLT.  Largely it'll depend on your
>data, your host's memory and CPU utilization, network speed and traffic,
>etc.  Most of my SDLT installations tend to top out around 10mB/sec,
>largely due to network congestion.  Gigabit is getting cheaper and is one
>of the first things I recommend to clients, even if only for the media
>servers and big data servers.
> > As anyone a Idea about this problem? How can I resolv it and what's
> > check, command or something else?
>Take a look at the tuning guide available from Veritas' knowledge base to
>assist you in tuning your buffering parameters.  SDLT, and other linear
>drives (DLT, LTO, STK 3590, etc) don't slow down gracefully.  Either they
>run at *very* fast speeds or something significantly slower due to what's
>called shoe-shining.  The tape speed, as it moves by the head, isn't
>variable so if the drive's buffer gets empty it has to stop the tape and
>rewind to the last point where it wrote anything.  This is bad for the
>tape, bad for the head and bad for performance.  Adjusting Veritas'
>buffers can help ensure that the drive's hardware buffers never (or
>rarely) get empty.
>Hope this helps.
>Jason K. Schechner  -   check out and help ban spam-mail.
>"All HELL would break loose if time got hacked." - Bill Kearney 02-04-03
>---There is no TRUTH.  There is no REALITY.  There is no CONSISTENCY.---
>    ---There are no ABSOLUTE STATEMENTS   I'm very probably wrong.---
>Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu

Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu

<Prev in Thread] Current Thread [Next in Thread>
  • [Veritas-bu] RE: [Veritas -bu] Tape Drive speed, Chu, Hong <=