You name it, and our clients are attached that way. We've got 100, Gig, and
SAN clients all using this server for backups.

The DLTs are connected via Differential SCSI, two per interface. LTO1s are
attached via Diff SCSI, one per interface. LTO2s are on the SAN.

We've got Windows and UNIX clients. It's a very heterougenous environment.

Would these settings hurt the DLT performance?

The BPTM log shows about a 2:1 ratio of "waited for empty" versus "waited
for full" messages. 208 vs 105 in a 24-hour period. The wait values are all
over the place, and empty/full messages are all intermingled, so I don't
know how to interpret it.

-----Original Message-----
From: Stewart, Brian C [mailto:StewaBC AT NORTHAMERICA.Stortek DOT com]
Sent: Tuesday, December 07, 2004 10:41 PM
To: Kirsch, Mathew (Matt); 'veritas-bu AT mailman.eng.auburn DOT edu'
Subject: RE: [Veritas-bu] Backups running slower for no apparent reason?


Solaris and LTO. I would recommend setting your;
 - NET_BUFFER_SZ to 512K or 1M
 - SIZE_DATA_BUFFER to 128K or 256K
 - NUMBER_DATA_BUFFER to 64 or 128

This should put a little spring in your tape drive's step. Tuning buffers
aside I would guess your bottle neck is at the client level.
Multi-streaming, multiplexing can have great improvements.

You did not mention if your clients are 10/100 LAN, Gig E LAN or SAN
attached. You did not mention if your drives were direct SCSI, Point to
Point Fibre or on a SAN.

Search your BPTM log for "waited for" messages. This should tell you how log
the tape drive waited for the system or how long the system waited for the
tape drive.

The TAR command is the same as the NetBackup BPKAR command. Well sort of...
NetBackup uses the standard GNU-TAR utility under the covers to write to
tape. The standard TAR utility uses a block size of 10 bytes or 10 K, I
can't remember. This is an unacceptable value for any tape drive besides a
DAT-2 4mm drive. I like to use the command "tar -cvfb <block_size/2>
/dev/rmt/0 ... To specify a larger block size.