I am receiving the error “bptm(pid 3692) the tape device at index -1 has a maximum block size of 32768 bytes, a buffer size of 65536 cannot be used.” I have tried researching this error, but I am not finding anything that applies to my setup. The version we are using is Veritas NetBackup 6.5.4, and this is a new Overland tape drive. We have two other Overland tape drives that are working just fine. Did I miss a configuration step when we swapped out our third tape drive? From my research it sounds like I need to increase the buffer size, but I cannot find out HOW to increase the buffer size. Does anyone here know..? I appreciate any help. Thank you!!

This is usually caused by a limitation of the HBA, nothing to do with NBU of the drive itself. The tape drive tuning is set in two files <install path>\veritas\netbackup\db\config\NUMBER_DATA_BUFFERS Eg, 16 32 64 128 256 and so on (128 or 256 seems to good performance, but it is try and see) <install path>\veritas\netbackup\db\config\SIZE_DATA_BUFFERS eg (32768 65536 131072 262144 ) For modern drives, 262144 is a common value that gives good performance). Martin

what OS you are using? It is a SCSI of FC tapes? Try to upgrade the firmeware of the SCSI/FC card and the drivers of the card and tape. As a workaround you can change the buffer size to 32768 and use more number_data_buffers.

We are using Windows Server 2003 R2 (Service Pack 2), and we use SCSI. Also, your work around, that's is what I hear you can do.. but I do not know how. How do I change the buffer size?

Alrighty, I have found those files before and my SIZE_DATA_BUFFERS file was set to 32768. I have changed it to be the 262144. However, I do not have the NUMBER_DATA_BUFFERS file. Can I just create that file without issue? What exactly is it doing? Thank you!

http://www.symantec.com/business/support/index?page=content&id=TECH1724 it is better to fry to upgrade the firmware and the drivers of the card. Also try to use the native drivers of 2003 and not the cards one. sometime help.

Yep, just create it - without it it uses a default value, I think 16. Think of the data as water, and the memory buffers as buckets. The size of the bucket is size_data_buffer and the number of buckets is number_data_buffer Water (data) flows from the client to the bucket(s) and then from the buckets to the drives. The rules, The bucket has to be empty before it can be filled The bucket has to be full before it can be emptied to a drive (with a couple of exceptions, but we can ignore those). The catch is that the buckets are real memory, and the greater the size and number, the more memory required, and this is per straem of data running to a drive (so multiplexing has a big effect ...). Anyhow, the trick to drive performance is to always have a constant flow of data, so the speed at which the buckets can be filled is vital (usually down to network perrfomance and disk read performance of the clients). If the buckets fill slowly, those that were full get emptied quickly, and the drives stop - giving rise to poor performance and shoe shining, which is real bad for the tapes and drives. In activty monitor, on completion of job, you'll see two lines ... ... waited for empty buffer 50 times, delayed 1000 times ... waited for full buffer 234 times, delayed 300 000 times Yep, I made the numbers up, and picked them 'cos they looked nice ... :0) In this example, we see we waited more times for the full buffer (it's the delayed value we are interested in). This would show that the delays in the backup were mostly caused by something on the client side not allowing the buffers to fill, and thus bptm had to wait many many times for data to become available. Sometimes, we see that the greater value was waited for empty, this isusually caused by tuning settings (those I have explained). Sometimes, it can be caused by SAN/ HBA/ firmware / driver issues, or even faulty drives (or worn). Apart from the tuning settings, it is very very rare for NBU to be the cause of a performance issue (I'm sure it can happen, but in 5 years I don't remember seeing it). Hope this helps, Martin

NetBackup 6.5.4 - Changing Buffer size - New Tape Drive

18 Replies

StefanosM
Level 6
12 years ago
what OS you are using? It is a SCSI of FC tapes?

Try to upgrade the firmeware of the SCSI/FC card and the drivers of the card and tape.

As a workaround you can change the buffer size to 32768 and use more number_data_buffers.
MetalGirl
Level 3
12 years ago
We are using Windows Server 2003 R2 (Service Pack 2), and we use SCSI.

Also, your work around, that's is what I hear you can do.. but I do not know how. How do I change the buffer size?
mph999
Level 6
12 years ago
This is usually caused by a limitation of the HBA, nothing to do with NBU of the drive itself.

The tape drive tuning is set in two files

<install path>\veritas\netbackup\db\config\NUMBER_DATA_BUFFERS

Eg, 16 32 64 128 256 and so on (128 or 256 seems to good performance, but it is try and see)

<install path>\veritas\netbackup\db\config\SIZE_DATA_BUFFERS

eg (32768 65536 131072 262144 )

For modern drives, 262144 is a common value that gives good performance).

Martin
MetalGirl
Level 3
12 years ago
Alrighty, I have found those files before and my SIZE_DATA_BUFFERS file was set to 32768. I have changed it to be the 262144.

However, I do not have the NUMBER_DATA_BUFFERS file. Can I just create that file without issue? What exactly is it doing?

Thank you!
StefanosM
Level 6
12 years ago
http://www.symantec.com/business/support/index?page=content&id=TECH1724

it is better to fry to upgrade the firmware and the drivers of the card. Also try to use the native drivers of 2003 and not the cards one. sometime help.
mph999
Level 6
12 years ago
Yep, just create it - without it it uses a default value, I think 16.

Think of the data as water, and the memory buffers as buckets.

The size of the bucket is size_data_buffer and the number of buckets is number_data_buffer

Water (data) flows from the client to the bucket(s) and then from the buckets to the drives.

The rules,

The bucket has to be empty before it can be filled

The bucket has to be full before it can be emptied to a drive (with a couple of exceptions, but we can ignore those).

The catch is that the buckets are real memory, and the greater the size and number, the more memory required, and this is per straem of data running to a drive (so multiplexing has a big effect ...).

Anyhow, the trick to drive performance is to always have a constant flow of data, so the speed at which the buckets can be filled is vital (usually down to network perrfomance and disk read performance of the clients). If the buckets fill slowly, those that were full get emptied quickly, and the drives stop - giving rise to poor performance and shoe shining, which is real bad for the tapes and drives.

In activty monitor, on completion of job, you'll see two lines ...

... waited for empty buffer 50 times, delayed 1000 times

... waited for full buffer 234 times, delayed 300 000 times

Yep, I made the numbers up, and picked them 'cos they looked nice ... :0)

In this example, we see we waited more times for the full buffer (it's the delayed value we are interested in). This would show that the delays in the backup were mostly caused by something on the client side not allowing the buffers to fill, and thus bptm had to wait many many times for data to become available.

Sometimes, we see that the greater value was waited for empty, this isusually caused by tuning settings (those I have explained). Sometimes, it can be caused by SAN/ HBA/ firmware / driver issues, or even faulty drives (or worn).

Apart from the tuning settings, it is very very rare for NBU to be the cause of a performance issue (I'm sure it can happen, but in 5 years I don't remember seeing it).

Hope this helps,

Martin
mph999
Level 6
12 years ago
Hmm ...

"I am receiving the error “bptm(pid 3692) the tape device at index -1 has a maximum block size of 32768 bytes, a buffer size of 65536 cannot be used."

Not sure 262144 will work, looks like the maximum is 32768.

Feel free to try, but I think it will fail

Some Tns

Seems drivers and OS settings can also be a cause.

http://www.symantec.com/business/support/index?page=content&id=TECH60400

http://www.symantec.com/business/support/index?page=content&id=TECH22746

http://www.backupcentral.com/phpBB2/two-way-mirrors-of-external-mailing-lists-3/symantec-netbackup-18/limitations-on-size-data-buffers-52319/
MetalGirl
Level 3
12 years ago
Thank you Stefanos and mph999 for the clarification and the links! It has made a bit clearer.

And mph99, yes, the buffer size of 262144 didn’t work. It even made the other two stop working. But when I changed it back to be 32768 the original two started working again, and the replaced one still didn’t. I don’t quite understand why it thinks that I have the buffer set to be 65536 when all of the files say 32768.

I am going to look through the documentation that you have posted and try to update the drivers.

I’ll keep you posted, and thank you so much!
Stumpr2
Level 6
12 years ago
bplabel the media
Marianne
Level 6
12 years ago

... the replaced one still didn’t. I don’t quite understand why it thinks that I have the buffer set to be 65536 when all of the files say 32768.

If there is a typo error in the file name or if it has .txt extention, the file will be ignored and the default of 65536 will be used.