Re: [Veritas-bu] 9940B

Mon, 16 Oct 2006 08:32:41 -0700

Much appreciated once again everyone for the response on this topic, the info has certainly made things a lot clearer.
 
Additionally I have run some bpbkar32 tests to NULL and it would appear in some instances the server is struggling to provide the data.
 
Cheers again
 
Dave

From: Brenton Carbins [mailto:[EMAIL PROTECTED]
Sent: 16 October 2006 14:54
To: Clooney, David
Subject: RE: [Veritas-bu] 9940B

Hi David,
 
The issue with changing SIZE_DATA_BUFFERS is something like this. My knowledge is empirical, so the exact causes may be a little different:
 
When media of 100GB is labelled with a block size of 100k, the label (or perhaps media.db) records a clock count of 1,000,000.  So we write 500,000 blocks with a 100k block size, and then change the block site to 200k. The recorded remaining block count is 500,000, but in practice, it is now only 250,000. But NetBackup will happily append the tape, until it has written a further 250,000 blocks. On the 250,001st block, there is no tape left, and we get a 174 Error. Basically, the time taken to write the 250,000 blocks (at 200k/block) is lost, as the job will have to restart, or perhaps fail, according to job configuration, window, etc.
 
Therefore, in order to avoid 174 errors, the media recorded with a block size of 100k cannot be rewritten with 200k blocks until they have been relabelled. Now, change the numbers to reflect actual SIZE_DATA_BUFFERS, and the maths still holds.
 
I have attached a note that I wrote some years ago, but have found generally useful up to version 5.1. Perhaps the most helpful will be the last page. Please note also I have had 9940B drives averaging 55-60MB/s, peaking at 70MB/s with one customer, and these same tuning notes have been used to obtain over 100MB/s with VTLs at another site.
 
I trust this is of some help to you.
 
Brenton
 



Brenton Carbins
Senior Systems Engineer
WA and SA Enterprise Products
Symantec Corporation
www.symantec.com
-----------------------------------------------------
Office: 08 9480 3720
Mobile: 0409 779 230
Fax: 08 9481 3177
Email: [EMAIL PROTECTED]
-----------------------------------------------------
Symantec Logo

Compelling New Features
Low Bandwidth, Remote Office Backup
http://www.symantec.com/Products/enterprise?c=newfeatures&refId=1381
 

From: Clooney, David [mailto:[EMAIL PROTECTED]
Sent: Monday, 16 October 2006 6:08 PM
To: Brenton Carbins
Cc: veritas-bu@mailman.eng.auburn.edu
Subject: RE: [Veritas-bu] 9940B

Much appreciated for the response Brenton
 
I have performed some tests after analysing bpbkar and bptm logs all all media servers and a number of their bptm logs indicate that they are not waiting for empty buffers, in turn telling me that an increase of the buffer size and number should have a positive impact .
 
 After testing our throughput has jumped around from around 11mb/sec to 40+ mb/sec which is fantastic, my concern is for the latter part of your mail regarding tapes which have been written with a different
SIZE_DATA_BUFFERS.
 
When testing I took backups before and after the SIZE_DATA_BUFFERS implementation. I then proceeded to test restores from both images written with different Buffer sizes.
All where successful however could you shed a little more light on this as we obviously have all our backed up data written in the current SIZE_DATA_BUFFER and it would be a shame not to achieve the throughput we saw when testing.
 
 
Thanks in advance
 
Dave

 

From: Brenton Carbins [mailto:[EMAIL PROTECTED]
Sent: 16 October 2006 01:32
To: Clooney, David
Subject: RE: [Veritas-bu] 9940B

Hi David,
 
 
My clients running 9940B drives are all running a SIZE_DATA_BUFFERS of 262144, with NUMBER_DATA_BUFFERS less important, and dependent on system resources and kernel settings. I'd suggest 32-64 buffers if you can achieve this without Error 11s. It is important when you are changing these settings that you test with maximum anticipated multiplexing and the maximum anticipated number of drives running, so that resource usage will hit it's peak, and any problems detected immediately.
 
If you already have lots media written with a different SIZE_DATA_BUFFER - say 131072, it is probably better not to change this value. If you do change this value, you will need to re-label existing media before attempting to write to them again. This may require that you suspend media until existing images expire.
 
Best of luck,
 
 
 
Brenton
 



Brenton Carbins
Senior Systems Engineer
WA and SA Enterprise Products
Symantec Corporation
-----------------------------------------------------
Office: 08 9480 3720
Mobile: 0409 779 230
Fax: 08 9481 3177
Email: [EMAIL PROTECTED]
-----------------------------------------------------
Symantec Logo

Compelling New Features
 

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Clooney, David
Sent: Friday, 13 October 2006 6:09 PM
To: veritas-bu@mailman.eng.auburn.edu
Subject: [Veritas-bu] 9940B

Hi
 
Was wondering whether anyone knows the max I/O buffer size for the STK 9940B ?
 
Trying to fine tune some media servers using the SIZE_DATA_BUFFERS and NUMBER_DATA_BUFFERS.
 
And was thinking the drive would obviously determine what the settings should be.
 
Regards
 
Dave


Notice to recipient:
The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity.

If this email originates from the U.K. please note that Bank of America, N.A., London Branch and Banc of America Securities Limited are authorised and regulated by the Financial Services Authority.



Notice to recipient:
The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity.

If this email originates from the U.K. please note that Bank of America, N.A., London Branch and Banc of America Securities Limited are authorised and regulated by the Financial Services Authority.



Notice to recipient:
The information in this internet e-mail and any attachments is confidential and may be privileged. It is intended solely for the addressee. If you are not the intended addressee please notify the sender immediately by telephone. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful.

When addressed to external clients any opinions or advice contained in this internet e-mail are subject to the terms and conditions expressed in any applicable governing terms of business or client engagement letter issued by the pertinent Bank of America group entity.

If this email originates from the U.K. please note that Bank of America, N.A., London Branch and Banc of America Securities Limited are authorised and regulated by the Financial Services Authority.

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

Reply via email to