Veritas-bu

[Veritas-bu] Streaming and large data sets

2004-03-19 13:29:19
Subject: [Veritas-bu] Streaming and large data sets
From: david.chapa AT adic DOT com (David Chapa)
Date: Fri, 19 Mar 2004 11:29:19 -0700
Justin:

It's a matter of balance and testing.

I'd run some tests using tar or dd going to dev/null to see how fast the
disk is for one stream, then I would do the same test with the # of
streams you are pulling with NBU.

This will give you an idea of what you can expect to be fed into the
bptm process on the media server.


David A. Chapa * Technical Advisor, Technical Marketing * ADIC *
720.249.5836 * david.chapa AT adic DOT com

The FUTURE is HERE - http://www.adic.com/gopathlightvx


-----Original Message-----
From: veritas-bu-admin AT mailman.eng.auburn DOT edu
[mailto:veritas-bu-admin AT mailman.eng.auburn DOT edu] On Behalf Of Justin C.
Lloyd
Sent: Friday, March 19, 2004 10:28 AM
To: veritas-bu AT mailman.eng.auburn DOT edu
Subject: [Veritas-bu] Streaming and large data sets

Ok, maybe I'm missing something.

One recommendation regarding streaming is not to have multiple streams 
off the same physical device.  By physical device, I am also taking that

to mean a RAID device that spans multiple disks and/or disk arrays.  In 
my case I have four arrays partitioned into 11 LUNs each and then my 
filesystem is built on a volume striped across all 44 LUNs.

So, I have a 400 GB (for now, but growing) data set on that filesystem. 
  My library's 8 AIT-3 tape drives can write at up to 40 GB/h each. 
Therefore if I were to have a single stream the data set would take 10 
hours to back up.  But if I want it to complete in, say, 2 hours, I'd 
have to use 4 drives and hence define 4 roughly equal size streams 
(which is what I currently do), which I occasionally have to rebalance 
as the data set grows.  But this streaming goes against the above 
recommendation.

It's possible this really isn't a problem if it just boils down to the 
drawback of the streaming taking more time due to additional head 
movement.  Breaking up a huge stream more than compensates for that 
overhead.

Any comments or suggestions?

Justin

-- 
Justin C. Lloyd
Unix System Administrator
MCI System Technology Solutions
Office 703.886.3219 Vnet 806.3219

_______________________________________________
Veritas-bu maillist  -  Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu


<Prev in Thread] Current Thread [Next in Thread>