Much has been written on this subject already yet it continues to be a topic fraught with pitfalls and mired in confusion. Perhaps by describing the way NetBackup's tape writing (as implemented in bptm process) operates some of this veil can be lifted and tape drives can be made to hum more efficiently.

For each NetBackup job stream writing to tape, a bptm process is launched. Part of its launch information packet includes a description of the source of its data, i.e. the client machine, the NetBackup policy and schedule, etc. However, the first bptm process does not directly concern itself with contacting the client, instead, it forks off a child process to start listening on a predetermined TCP/IP socket for the client to contact it. The parent process meanwhile proceeds to allocate, open and otherwise prepare a tape and a tape drive to start writing the eagerly anticipated client data.
Next comes the description of how to the two pass this client data between eachother.

Obviously the two bptm processes need to hand the data read from the TCP/IP socket on to the tape writer as efficiently as possibly, preferrably without copying it around anymore than necessary. To this end they make use of an operating system feature known as shared memory. By default 8 32KByte buffers are set aside for this very purpose. The child copies the incoming network data stream into these buffers while the parent hands them off directly to the target tape device driver to be written out.

A few observations about these buffers then:

• First, note how the parent hands the buffer directly to the tape device driver, i.e. the write requests to tape will be of the exact same size as your buffers. The underlying reason is to avoid having to copy data around but this does mean that the NetBackup buffer size will equal your tape devices' block sizes. The size of this buffer can be tuned by creating a file called SIZE_DATA_BUFFERS at

  /usr/openv/netbackup/db/config
  

• Second, no matter how big or how many buffers are allocated, if there is a gross mismatch between the rate at which the child fills the buffers and the parent empties them, fiddling with the size and quantity of these buffers will have no effect. However, if either bptm process performs erratically, much can be gained from a well-chosen set of buffers to help smooth over the bumps.
  By the way, the number of buffers is controlled with the file NUMBER_DATA_BUFFERS in the same place as shown above.
• Finally, the penalty for running out of empty buffers for the child to write incoming data into is meted out in 20 millisecond increments (tunable).
  Conversely, running out of full buffers for the parent process to hand off to the tape device incurs delays in increments of 30 milliseconds (also tunable). However, that penalty is nothing compared to the amount of time it takes the tape drive itself to stop, rewind somewhat and take another running start at writing the next buffer once it becomes available.

A future installment will deal with the analysis of a NetBackup environment in determining optimal buffer size and quantity settings.