Video Screencast Help

NetBackup 6.5.4 - Changing Buffer size - New Tape Drive

Created: 18 Mar 2013 • Updated: 10 May 2013 | 18 comments
This issue has been solved. See solution.

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!!

Operating Systems:

Comments 18 CommentsJump to latest comment

StefanosM's picture

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's picture

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's picture

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).


Regards,  Martin
Setting Logs in NetBackup:
MetalGirl's picture

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's picture

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's picture

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,


Regards,  Martin
Setting Logs in NetBackup:
mph999's picture

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.

Regards,  Martin
Setting Logs in NetBackup:
MetalGirl's picture

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's picture

bplabel the media

VERITAS ain't it the truth?

Marianne's picture

... 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.

Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Mark_Solutions's picture

Not sure if you have more than one media server but every media server needs to have the buffer files to be able to use them - i doubt that is the issue if they are scsi attached

Perhaps during the swapout the SCSI card has reset itself so do look at that first as this is where the limit is set.

So take in the registry under HKLM\System\CurrentControlSet\Services\DeviceDriver\Parameters\Device\ looking for your SCSI device as the "devicename"

Look for the value of MaximumSGList - this needs to be enough to allow the 64kb or more setting - here is an adaptec artice explaining it:

A driver upgrade may also help, if it is an adaptec card DO NOT use Windows drivers - they are very, very slow!

Hope this helps

Authorised Symantec Consultant . Expert Partner.

Don't forget to "Mark as Solution" if someones advice has solved your issue - and please bring back the Thumbs Up!!.

MetalGirl's picture

Alrighty, I have updated the firmware on one of the tape drives (but not the one that wasn’t working). The one that wasn’t working was already at version 5.10. These are fairly old tape drives (Overland ArcVaults 24)  and it looks like this firmware update (from 2008) is the last one that was released. If I’m wrong please let me know! So, now all three of them are at version 5.10.

The file type for the NUMBER_DATA_BUFFERS and SIZE_DATA_BUFFERS is just “file” not .txt.

It looks like we are using the Microsoft drivers (for the Medium Changers) which I will be looking in to replacing, but all three tape drives are using the same version driver. The only difference I can really see is with the drivers for the Tape Drives. The two working ones are Hewlett Packard LTO Ultrium-3 version, and the one that isn’t working has a newer version Hewlett Packard LTO Ultrium-3

Another good tid bit about our set up is that the one that is not working is plugged into a media server and the two working ones are plugged into the master server.

I’m going to try updating the drivers for the medium changer, but I don’t think that is the cause of this particular problem. However, they may help with our speed issue.

Mark_Solutions, I will also be looking into the SCSCI settings you mentioned, but if anybody else has more suggestions I would very much appreciate it! Even though this is a very annoying problem I am learning a lot!

StefanosM's picture

Try to move the non working drive to the master server for test.

If will work, then the scsi card on the media server is the problem (card itself, firmware,drivers) .

MetalGirl's picture

 I apologize for the delay, but it is a never ending stream of things that need to be done. Luckily I was able to get the tape drive to start cooperating by doing this:

  1. Deleted the device and the robot from NBU on the master server
  2. Shut down all three tape drives
  3. Shut down both the master sever and the media server
  4. Turned on all three tape drives
  5. After all three tape drives were completely up I turned on the servers
  6. Then once everything was up I re-added the device and robot into NBU

And it has been working just fine ever since (the past week and a half). Thank you again for all the help! I learned a lot from all the troubleshooting!

Marianne's picture

Are you saying that the buffer size error disappeared by just shutting down and restarting everything?

No buffer size file was modified on the media server and no registry setting changed?


Supporting Storage Foundation and VCS on Unix and Windows as well as NetBackup on Unix and Windows
Handy NBU Links

Ankit Maheshwari's picture

Marianne!! Not sure but i think after making changing the value of size_data_buffer and color:#333333">number_data_buffer we need to restart the services.

MetaGreil created the number_data_buffer file but didn't restarted services.


So after restarting the services its working fine..


Ankit Maheshwari

mph999's picture

No, no retstart required.

These values are read by bptm, so the only thing that needs to happenn, is bptm has to start a new process.  It will do this when a new backup starts.

Regards,  Martin
Setting Logs in NetBackup:
mph999's picture

Agree with Marianne, strtange solution, didn't expect that.

Sometimes, a restart / reconfig  / reboot fixes things, even though there is no real reason it should.

With drive/ library issues, it is quite often worth doing this at the beginning of the problem, it might fix things, and even if not, you have eliminated the restart/ reconfig as a possible cause.

I've only even seen HBA issues cause this fault in the past, so that was a anew one to me ..

Regards,  Martin
Setting Logs in NetBackup: