KB Logo

TOLIS Group Knowledge Base

Browse KB by category:
Go to KB #:
Glossary
Email   Bookmark



What are the proper settings for my tape drive or library and how does the BRU I/O buffer work?

Views: 22221
Votes: 17
Posted: 23 Apr, 2007

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.

Figure 1
Bell Curve
Using settings that are too lower or too high will cause the system to wait on the drive or vise-versa ("Y" and "Z"). The goal is to make both work consistently ("X").

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.

Figure 2
BRU I/O Process

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.

Others in this Category
document How do I save time erasing tapes in Linux?
document Does BRU perform Synthetic Backups?
document Image based backups versus file-by-file backups. Competitive or Complimentary Technologies?
document Understanding Unix/Linux Timestamp's
document How do I properly rotate my tapes for incremental or differential backups?
» More Articles



RSS
Powered by KnowledgebasePublisher
Page Load Time: 0.034187 seconds / 34.187 milliseconds.
Page File Size: 28936 bytes.