How Does the BRU Block Size and Buffer/Write-Cache Work Together?
TOLIS Group has done a lot of testing on many different forms of tape media, primarily LTO and DAT, to determine the general settings that work for different tape devices. We have found that the optimal performance for tape drives in general varies system to system and the environment in which each tape device is used. When testing tape performance, the goal is to allow a steady flow of data into the system and out to the tape drive, thus making the system and tape drive constantly working instead of one or the other sitting dormant for any length of time waiting for a process to catch up.
You can view the manufacturer reported drive speeds on the Tape Drive Performance page. This page reports the stats of what drive manufacturers report the native top-speed of various drives that they make. These are not TOLIS Group or TCP tested numbers.
To better understand how BRU performs the I/O when a buffer or write cache work, you must first understand how it is that BRU controls the buffer stream and thus the amount of data dumped on the tape drive. Before we get started explaining this process, think of a bell curve. Higher write cache sizes do not mean the drive will go faster, nor does a lower write cache mean that your drive will go slower. The idea is to find the write cache and block size combination that works best for your particular environment.
Setting the write cache too high can cause the drive to wait longer on the system ("Z" in Figure 1) because it's taking longer to build the larger write cache; setting the value too low can cause the system to wait on the tape drive ("Y" in Figure 1) because the system is building data faster than the tape drive can write the data. The goal you want is to find what keeps both the system and the tape drive working so neither has to wait ("X" in Figure 1).
Figure 2 shows how the backup is performed to a tape device with the write cache as physical RAM in the system. The speed of the RAM that you have can greatly provide different results on different systems. A larger write caches doesn't mean faster, nor does a lower write cache mean slower. Think of the drive, RAM, hard disk, and transfer type (SCSI, Fibre Channel, FireWire, etc.) all having major roles in the way that the tape drive performance can be affected. It would look like a bell-curve. Each system will operate differently. While 128 KB block size with a 256 MB write buffer would work on one system and 256 KB with a 512 MB buffer will work better on another.
BRU Server uses a circular buffer I/O, meaning that BRU can build a write buffer, 256 MB for example, and when it's completed building that buffer, it will send the data to the drive while starting a new 512 MB buffer. Due to hardware, drives, RAM, and many other factors, each system will operate differently under different speeds. Try changing the buffer size before you change the block size. Changing the block size results in BRU Server not bing able to read the other archiveson your tapes written in a different block size. For example, when BRU Server is set to 128 KB (default) for its block size, it cannot read a tape written in 256 KB block size. It will result in a read error. You must then change your block size from the custom setting (256 KB in this example) to the default setting of 128 KB so that BRU Server can read the tape to restore your data. When you're done with the restore, you'll then need to make sure that you change the block size back to the custom setting.
Hopefully this gives you a better understanding of the BRU I/O engine and how it operates to get the best performance from your tape device. Once you have found the optimal settings for your tape device, they should then be applied to the system when you start using BRU Server for your actual production backup operations. For suggested settings for your tape device that may provide a good starting point for you, please see KB #56.