4 \chapter{Testing Your Tape Drive With Bacula}
5 \label{TapeTestingChapter}
6 \index[general]{Testing Your Tape Drive With Bacula}
8 This chapter is concerned with testing and configuring your tape drive to make
9 sure that it will work properly with Bacula using the {\bf btape} program.
12 \section{Get Your Tape Drive Working}
14 In general, you should follow the following steps to get your tape drive to
15 work with Bacula. Start with a tape mounted in your drive. If you have an
16 autochanger, load a tape into the drive. We use {\bf /dev/nst0} as the tape
17 drive name, you will need to adapt it according to your system.
19 Do not proceed to the next item until you have succeeded with the previous
23 \item Make sure that Bacula (the Storage daemon) is not running
24 or that you have {\bf unmount}ed the drive you will use
27 \item Use tar to write to, then read from your drive:
31 mt -f /dev/nst0 rewind
33 mt -f /dev/nst0 rewind
39 \item Make sure you have a valid and correct Device resource corresponding
40 to your drive. For Linux users, generally, the default one works. For
41 FreeBSD users, there are two possible Device configurations (see below).
42 For other drives and/or OSes, you will need to first ensure that your
43 system tape modes are properly setup (see below), then possibly modify
44 you Device resource depending on the output from the btape program (next
45 item). When doing this, you should consult the \borgxrlink{Storage Daemon
46 Configuration}{StoredConfChapter}{main}{chapter} of the \mainman{}.
48 \item If you are using a Fibre Channel to connect your tape drive to
49 Bacula, please be sure to disable any caching in the NSR (network
50 storage router, which is a Fibre Channel to SCSI converter).
52 \item Run the btape {\bf test} command:
56 ./btape -c bacula-sd.conf /dev/nst0
62 It isn't necessary to run the autochanger part of the test at this time,
63 but do not go past this point until the basic test succeeds. If you do
64 have an autochanger, please be sure to read the \borgxrlink{Autochanger
65 chapter}{AutochangersChapter}{main}{chapter} of the \mainman{}.
67 \item Run the btape {\bf fill} command, preferably with two volumes. This
68 can take a long time. If you have an autochanger and it is configured, Bacula
69 will automatically use it. If you do not have it configured, you can manually
70 issue the appropriate {\bf mtx} command, or press the autochanger buttons to
71 change the tape when requested to do so.
73 \item FreeBSD users, if you have a pre-5.0 system run the {\bf tapetest}
74 program, and make sure your system is patched if necessary. The tapetest
75 program can be found in the platform/freebsd directory. The instructions
76 for its use are at the top of the file.
78 \item Run Bacula, and backup a reasonably small directory, say 60
79 Megabytes. Do three successive backups of this directory.
81 \item Stop Bacula, then restart it. Do another full backup of the same
82 directory. Then stop and restart Bacula.
84 \item Do a restore of the directory backed up, by entering the following
85 restore command, being careful to restore it to an alternate location:
90 restore select all done
96 Do a {\bf diff} on the restored directory to ensure it is identical to the
97 original directory. If you are going to backup multiple different systems
98 (Linux, Windows, Mac, Solaris, FreeBSD, ...), be sure you test the restore
101 \item If you have an autochanger, you should now go back to the btape program
102 and run the autochanger test:
106 ./btape -c bacula-sd.conf /dev/nst0
112 Adjust your autochanger as necessary to ensure that it works correctly. See
113 the Autochanger chapter of this manual for a complete discussion of testing
116 \item We strongly recommend that you use a dedicated SCSI
117 controller for your tape drives. Scanners are known to induce
118 serious problems with the SCSI bus, causing it to reset. If the
119 SCSI bus is reset while Bacula has the tape drive open, it will
120 most likely be fatal to your tape since the drive will rewind.
121 These kinds of problems show up in the system log. For example,
122 the following was most likely caused by a scanner:
126 Feb 14 17:29:55 epohost kernel: (scsi0:A:2:0): No or incomplete CDB sent to device.
127 Feb 14 17:29:55 epohost kernel: scsi0: Issued Channel A Bus Reset. 1 SCBs aborted
133 If you have reached this point, you stand a good chance of having everything
134 work. If you get into trouble at any point, {\bf carefully} read the
135 documentation given below. If you cannot get past some point, ask the {\bf
136 bacula-users} email list, but specify which of the steps you have successfully
137 completed. In particular, you may want to look at the \ilink{Tips for Resolving Problems}{problems1} section below.
140 \label{NoTapeInDrive}
141 \subsection{Problems When no Tape in Drive}
142 \index[general]{Problems When no Tape in Drive}
143 When Bacula was first written the Linux 2.4 kernel permitted opening the
144 drive whether or not there was a tape in the drive. Thus the Bacula code is
145 based on the concept that if the drive cannot be opened, there is a serious
146 problem, and the job is failed.
148 With version 2.6 of the Linux kernel, if there is no tape in the drive, the
149 OS will wait two minutes (default) and then return a failure, and consequently,
150 Bacula version 1.36 and below will fail the job. This is important to keep
151 in mind, because if you use an option such as {\bf Offline on Unmount =
152 yes}, there will be a point when there is no tape in the drive, and if
153 another job starts or if Bacula asks the operator to mount a tape, when
154 Bacula attempts to open the drive (about a 20 minute delay), it will fail
155 and Bacula will fail the job.
157 In version 1.38.x, the Bacula code partially gets around this problem -- at
158 least in the initial open of the drive. However, functions like Polling
159 the drive do not work correctly if there is no tape in the drive.
160 Providing you do not use {\bf Offline on Unmount = yes}, you should not
161 experience job failures as mentioned above. If you do experience such
162 failures, you can also increase the {\bf Maximum Open Wait} time interval,
163 which will give you more time to mount the next tape before the job is
166 \subsection{Specifying the Configuration File}
167 \index[general]{File!Specifying the Configuration}
168 \index[general]{Specifying the Configuration File}
170 Starting with version 1.27, each of the tape utility programs including the
171 {\bf btape} program requires a valid Storage daemon configuration file
172 (actually, the only part of the configuration file that {\bf btape} needs is
173 the {\bf Device} resource definitions). This permits {\bf btape} to find the
174 configuration parameters for your archive device (generally a tape drive).
175 Without those parameters, the testing and utility programs do not know how to
176 properly read and write your drive. By default, they use {\bf bacula-sd.conf}
177 in the current directory, but you may specify a different configuration file
178 using the {\bf -c} option.
180 \subsection{Specifying a Device Name For a Tape}
181 \index[general]{Tape!Specifying a Device Name For a}
182 \index[general]{Specifying a Device Name For a Tape}
184 {\bf btape} {\bf device-name} where the Volume can be found. In the case of a
185 tape, this is the physical device name such as {\bf /dev/nst0} or {\bf
186 /dev/rmt/0ubn} depending on your system that you specify on the Archive Device
187 directive. For the program to work, it must find the identical name in the
188 Device resource of the configuration file. If the name is not found in the
189 list of physical names, the utility program will compare the name you entered
190 to the Device names (rather than the Archive device names).
192 When specifying a tape device, it is preferable that the "non-rewind"
193 variant of the device file name be given. In addition, on systems such as
194 Sun, which have multiple tape access methods, you must be sure to specify
195 to use Berkeley I/O conventions with the device. The
196 {\bf b} in the Solaris (Sun) archive specification {\bf /dev/rmt/0mbn} is
197 what is needed in this case. Bacula does not support SysV tape drive
200 See below for specifying Volume names.
202 \subsection{Specifying a Device Name For a File}
203 \index[general]{File!Specifying a Device Name For a}
204 \index[general]{Specifying a Device Name For a File}
206 If you are attempting to read or write an archive file rather than a tape, the
207 {\bf device-name} should be the full path to the archive location including
208 the filename. The filename (last part of the specification) will be stripped
209 and used as the Volume name, and the path (first part before the filename)
210 must have the same entry in the configuration file. So, the path is equivalent
211 to the archive device name, and the filename is equivalent to the volume name.
216 \index[general]{Btape}
218 This program permits a number of elementary tape operations via a tty command
219 interface. The {\bf test} command, described below, can be very useful for
220 testing tape drive compatibility problems. Aside from initial testing of tape
221 drive compatibility with {\bf Bacula}, {\bf btape} will be mostly used by
222 developers writing new tape drivers.
224 {\bf btape} can be dangerous to use with existing {\bf Bacula} tapes because
225 it will relabel a tape or write on the tape if so requested regardless of
226 whether or not the tape contains valuable data, so please be careful and use
227 it only on blank tapes.
229 To work properly, {\bf btape} needs to read the Storage daemon's configuration
230 file. As a default, it will look for {\bf bacula-sd.conf} in the current
231 directory. If your configuration file is elsewhere, please use the {\bf -c}
232 option to specify where.
234 The physical device name or the Device resource name must be specified on the
235 command line, and this same device name must be present in the Storage
236 daemon's configuration file read by {\bf btape}
240 Usage: btape [options] device_name
241 -b <file> specify bootstrap file
242 -c <file> set configuration file to file
243 -d <nn> set debug level to nn
244 -p proceed inspite of I/O errors
247 -? print this message.
251 \subsection{Using btape to Verify your Tape Drive}
252 \index[general]{Using btape to Verify your Tape Drive}
253 \index[general]{Drive!Using btape to Verify your Tape}
255 An important reason for this program is to ensure that a Storage daemon
256 configuration file is defined so that Bacula will correctly read and write
259 It is highly recommended that you run the {\bf test} command before running
260 your first Bacula job to ensure that the parameters you have defined for your
261 storage device (tape drive) will permit {\bf Bacula} to function properly. You
262 only need to mount a blank tape, enter the command, and the output should be
263 reasonably self explanatory. For example:
267 (ensure that Bacula is not running)
268 ./btape -c /usr/bin/bacula/bacula-sd.conf /dev/nst0
276 Tape block granularity is 1024 bytes.
277 btape: btape.c:376 Using device: /dev/nst0
282 Enter the test command:
290 The output produced should be something similar to the following: I've cut the
291 listing short because it is frequently updated to have new tests.
295 === Append files test ===
296 This test is essential to Bacula.
297 I'm going to write one record in file 0,
298 two records in file 1,
299 and three records in file 2
300 btape: btape.c:387 Rewound /dev/nst0
301 btape: btape.c:855 Wrote one record of 64412 bytes.
302 btape: btape.c:857 Wrote block to device.
303 btape: btape.c:410 Wrote EOF to /dev/nst0
304 btape: btape.c:855 Wrote one record of 64412 bytes.
305 btape: btape.c:857 Wrote block to device.
306 btape: btape.c:855 Wrote one record of 64412 bytes.
307 btape: btape.c:857 Wrote block to device.
308 btape: btape.c:410 Wrote EOF to /dev/nst0
309 btape: btape.c:855 Wrote one record of 64412 bytes.
310 btape: btape.c:857 Wrote block to device.
311 btape: btape.c:855 Wrote one record of 64412 bytes.
312 btape: btape.c:857 Wrote block to device.
313 btape: btape.c:855 Wrote one record of 64412 bytes.
314 btape: btape.c:857 Wrote block to device.
315 btape: btape.c:410 Wrote EOF to /dev/nst0
316 btape: btape.c:387 Rewound /dev/nst0
317 btape: btape.c:693 Now moving to end of media.
318 btape: btape.c:427 Moved to end of media
319 We should be in file 3. I am at file 3. This is correct!
320 Now the important part, I am going to attempt to append to the tape.
322 === End Append files test ===
326 If you do not successfully complete the above test, please resolve the
327 problem(s) before attempting to use {\bf Bacula}. Depending on your tape
328 drive, the test may recommend that you add certain records to your
329 configuration. We strongly recommend that you do so and then re-run the above
330 test to insure it works the first time.
332 Some of the suggestions it provides for resolving the problems may or may not
333 be useful. If at all possible avoid using fixed blocking. If the test suddenly
334 starts to print a long series of:
344 then almost certainly, you are running your drive in fixed block mode rather
345 than variable block mode. See below for more help of resolving fix
346 versus variable block problems.
348 It is also possible that you have your drive
349 set in SysV tape drive mode. The drive must use BSD tape conventions.
350 See the section above on setting your {\bf Archive device} correctly.
352 For FreeBSD users, please see the notes below for doing further testing of
355 \subsection{Testing tape drive speed}
356 \label{sec:btapespeed}
358 To determine the best configuration of your tape drive, you can run the
359 \texttt{speed} command available in the \texttt{btape} program.
361 This command can have the following arguments:
363 \item[\texttt{file\_size=n}] Specify the Maximum File Size for this test
364 (between 1 and 5GB). This counter is in GB.
365 \item[\texttt{nb\_file=n}] Specify the number of file to be written. The amount
366 of data should be greater than your memory ($file\_size*nb\_file$).
367 \item[\texttt{skip\_zero}] This flag permits to skip tests with constant
369 \item[\texttt{skip\_random}] This flag permits to skip tests with random
371 \item[\texttt{skip\_raw}] This flag permits to skip tests with raw access.
372 \item[\texttt{skip\_block}] This flag permits to skip tests with Bacula block
377 *speed file_size=3 skip_raw
378 btape.c:1078 Test with zero data and bacula block structure.
379 btape.c:956 Begin writing 3 files of 3.221 GB with blocks of 129024 bytes.
380 ++++++++++++++++++++++++++++++++++++++++++
381 btape.c:604 Wrote 1 EOF to "Drive-0" (/dev/nst0)
382 btape.c:406 Volume bytes=3.221 GB. Write rate = 44.128 MB/s
384 btape.c:383 Total Volume bytes=9.664 GB. Total Write rate = 43.531 MB/s
386 btape.c:1090 Test with random data, should give the minimum throughput.
387 btape.c:956 Begin writing 3 files of 3.221 GB with blocks of 129024 bytes.
388 +++++++++++++++++++++++++++++++++++++++++++
389 btape.c:604 Wrote 1 EOF to "Drive-0" (/dev/nst0)
390 btape.c:406 Volume bytes=3.221 GB. Write rate = 7.271 MB/s
391 +++++++++++++++++++++++++++++++++++++++++++
393 btape.c:383 Total Volume bytes=9.664 GB. Total Write rate = 7.365 MB/s
397 When using compression, the random test will give your the minimum throughput
398 of your drive . The test using constant string will give you the maximum speed
399 of your hardware chain. (cpu, memory, scsi card, cable, drive, tape).
401 You can change the block size in the Storage Daemon configuration file.
404 \subsection{Linux SCSI Tricks}
405 \index[general]{Tricks!Linux SCSI}
406 \index[general]{Linux SCSI Tricks}
408 You can find out what SCSI devices you have by doing:
420 [0:0:0:0] disk ATA ST3160812AS 3.AD /dev/sda
421 [2:0:4:0] tape HP Ultrium 2-SCSI F6CH /dev/st0
422 [2:0:5:0] tape HP Ultrium 2-SCSI F6CH /dev/st1
423 [2:0:6:0] mediumx OVERLAND LXB 0107 -
424 [2:0:9:0] tape HP Ultrium 1-SCSI E50H /dev/st2
425 [2:0:10:0] mediumx OVERLAND LXB 0107 -
429 There are two drives in one autochanger: /dev/st0 and /dev/st1
430 and a third tape drive at /dev/st2. For using them with Bacula, one
431 would normally reference them as /dev/nst0 ... /dev/nst2. Not also,
432 there are two different autochangers identified as "mediumx OVERLAND LXB".
433 They can be addressed via their /dev/sgN designation, which can be
434 obtained by counting from the beginning as 0 to each changer. In the
435 above case, the two changers are located on /dev/sg3 and /dev/sg5. The one
436 at /dev/sg3, controls drives /dev/nst0 and /dev/nst1; and the one at
437 /dev/sg5 controles drive /dev/nst2.
439 If you do not have the {\bf lsscsi} command, you can obtain the same
440 information as follows:
448 For the above example with the three drives and two autochangers,
454 Host: scsi0 Channel: 00 Id: 00 Lun: 00
455 Vendor: ATA Model: ST3160812AS Rev: 3.AD
456 Type: Direct-Access ANSI SCSI revision: 05
457 Host: scsi2 Channel: 00 Id: 04 Lun: 00
458 Vendor: HP Model: Ultrium 2-SCSI Rev: F6CH
459 Type: Sequential-Access ANSI SCSI revision: 03
460 Host: scsi2 Channel: 00 Id: 05 Lun: 00
461 Vendor: HP Model: Ultrium 2-SCSI Rev: F6CH
462 Type: Sequential-Access ANSI SCSI revision: 03
463 Host: scsi2 Channel: 00 Id: 06 Lun: 00
464 Vendor: OVERLAND Model: LXB Rev: 0107
465 Type: Medium Changer ANSI SCSI revision: 02
466 Host: scsi2 Channel: 00 Id: 09 Lun: 00
467 Vendor: HP Model: Ultrium 1-SCSI Rev: E50H
468 Type: Sequential-Access ANSI SCSI revision: 03
469 Host: scsi2 Channel: 00 Id: 10 Lun: 00
470 Vendor: OVERLAND Model: LXB Rev: 0107
471 Type: Medium Changer ANSI SCSI revision: 02
476 As an additional example, I get the following (on a different machine from the
482 Host: scsi2 Channel: 00 Id: 01 Lun: 00
483 Vendor: HP Model: C5713A Rev: H107
484 Type: Sequential-Access ANSI SCSI revision: 02
485 Host: scsi2 Channel: 00 Id: 04 Lun: 00
486 Vendor: SONY Model: SDT-10000 Rev: 0110
487 Type: Sequential-Access ANSI SCSI revision: 02
491 The above represents first an autochanger and second a simple
492 tape drive. The HP changer (the first entry) uses the same SCSI channel
493 for data and for control, so in Bacula, you would use:
496 Archive Device = /dev/nst0
497 Changer Device = /dev/sg0
501 If you want to remove the SDT-10000 device, you can do so as root with:
505 echo "scsi remove-single-device 2 0 4 0">/proc/scsi/scsi
509 and you can put add it back with:
513 echo "scsi add-single-device 2 0 4 0">/proc/scsi/scsi
517 where the 2 0 4 0 are the Host, Channel, Id, and Lun as seen on the output
518 from {\bf cat /proc/scsi/scsi}. Note, the Channel must be specified as
521 Below is a slightly more complicated output, which is a single autochanger
522 with two drives, and which operates the changer on a different channel
523 from from the drives:
528 Host: scsi0 Channel: 00 Id: 00 Lun: 00
529 Vendor: ATA Model: WDC WD1600JD-75H Rev: 08.0
530 Type: Direct-Access ANSI SCSI revision: 05
531 Host: scsi2 Channel: 00 Id: 04 Lun: 00
532 Vendor: HP Model: Ultrium 2-SCSI Rev: F6CH
533 Type: Sequential-Access ANSI SCSI revision: 03
534 Host: scsi2 Channel: 00 Id: 05 Lun: 00
535 Vendor: HP Model: Ultrium 2-SCSI Rev: F6CH
536 Type: Sequential-Access ANSI SCSI revision: 03
537 Host: scsi2 Channel: 00 Id: 06 Lun: 00
538 Vendor: OVERLAND Model: LXB Rev: 0106
539 Type: Medium Changer ANSI SCSI revision: 02
543 The above tape drives are accessed on /dev/nst0 and /dev/nst1, while
544 the control channel for those two drives is /dev/sg3.
549 \section{Tips for Resolving Problems}
550 \index[general]{Problems!Tips for Resolving}
551 \index[general]{Tips for Resolving Problems}
553 \label{CannotRestore}
554 \subsection{Bacula Saves But Cannot Restore Files}
555 \index[general]{Files!Bacula Saves But Cannot Restore}
556 \index[general]{Bacula Saves But Cannot Restore Files}
558 If you are getting error messages such as:
562 Volume data error at 0:1! Wanted block-id: "BB02", got "". Buffer discarded
566 It is very likely that Bacula has tried to do block positioning and ended up
567 at an invalid block. This can happen if your tape drive is in fixed block mode
568 while Bacula's default is variable blocks. Note that in such cases, Bacula is
569 perfectly able to write to your Volumes (tapes), but cannot position to read
572 There are two possible solutions.
575 \item The first and best is to always ensure that your drive is in variable
576 block mode. Note, it can switch back to fixed block mode on a reboot or if
577 another program uses the drive. So on such systems you need to modify the
578 Bacula startup files to explicitly set:
582 mt -f /dev/nst0 defblksize 0
586 or whatever is appropriate on your system. Note, if you are running a Linux
587 system, and the above command does not work, it is most likely because you
588 have not loaded the appropriate {\bf mt} package, which is often called
589 {\bf mt\_st}, but may differ according to your distribution.
591 \item The second possibility, especially, if Bacula wrote while the drive was
592 in fixed block mode, is to turn off block positioning in Bacula. This is done
597 Block Positioning = no
601 to the Device resource. This is not the recommended procedure because it can
602 enormously slow down recovery of files, but it may help where all else
603 fails. This directive is available in version 1.35.5 or later (and not yet
607 If you are getting error messages such as:
610 Volume data error at 0:0!
611 Block checksum mismatch in block=0 len=32625 calc=345678 blk=123456
615 You are getting tape read errors, and this is most likely due to
616 one of the following things:
618 \item An old or bad tape.
619 \item A dirty drive that needs cleaning (particularly for DDS drives).
620 \item A loose SCSI cable.
621 \item Old firmware in your drive. Make sure you have the latest firmware
623 \item Computer memory errors.
624 \item Over-clocking your CPU.
625 \item A bad SCSI card.
630 \subsection{Bacula Cannot Open the Device}
631 \index[general]{Device!Bacula Cannot Open the}
632 \index[general]{Bacula Cannot Open the Device}
634 If you get an error message such as:
638 dev open failed: dev.c:265 stored: unable to open
639 device /dev/nst0:> ERR=No such device or address
643 the first time you run a job, it is most likely due to the fact that you
644 specified the incorrect device name on your {\bf Archive Device}.
646 If Bacula works fine with your drive, then all off a sudden you get error
647 messages similar to the one shown above, it is quite possible that your driver
648 module is being removed because the kernel deems it idle. This is done via
649 {\bf crontab} with the use of {\bf rmmod -a}. To fix the problem, you can
650 remove this entry from {\bf crontab}, or you can manually {\bf modprob} your
651 driver module (or add it to the local startup script). Thanks to Alan Brown
655 Sometimes the tape handler gets confused. This can happen if your tape
656 drive door is locked (Bacula locks it when writing a tape), and Bacula
657 crashes or some other problem occurs. After this kind of a problem,
658 the kernel driver will not recognize that a tape is loaded and you
659 may see messages such as:
663 19-Sep 16:39 groschat-sd JobId 16072: Warning: mount.c:219 Open of tape
664 device "LTO4-Drive" (/dev/tape/by-id/scsi-3500143801403cf22-nst) Volume
665 "AAJ372" failed: ERR=tape_dev.c:162 Unable to open device "LTO4-Drive"
666 (/dev/tape/by-id/scsi-3500143801403cf22-nst): ERR=No medium found
668 19-Sep 16:39 groschat-sd JobId 16072: Please mount append Volume "AAJ372"
669 or label a new one for:
670 Job: Rufus.2016-09-19_16.34.22_03
671 Storage: "LTO4-Drive" (/dev/tape/by-id/scsi-3500143801403cf22-nst)
677 in that case, the best thing to do is unload the tape by hand with:
681 mtx -f /dev/sgx unload
685 where you replace /dev/sgx by your scsi control device name.
689 \label{IncorrectFiles}
690 \subsection{Incorrect File Number}
691 \index[general]{Number!Incorrect File}
692 \index[general]{Incorrect File Number}
694 When Bacula moves to the end of the medium, it normally uses the {\bf
695 ioctl(MTEOM)} function. Then Bacula uses the {\bf ioctl(MTIOCGET)} function to
696 retrieve the current file position from the {\bf mt\_fileno} field. Some SCSI
697 tape drivers will use a fast means of seeking to the end of the medium and in
698 doing so, they will not know the current file position and hence return a {\bf
699 -1}. As a consequence, if you get {\bf "This is NOT correct!"} in the
700 positioning tests, this may be the cause. You must correct this condition in
701 order for Bacula to work.
703 There are two possible solutions to the above problem of incorrect file
707 \item Figure out how to configure your SCSI driver to keep track of the file
708 position during the MTEOM request. This is the preferred solution.
709 \item Modify the {\bf Device} resource of your {\bf bacula-sd.conf} file to
714 Hardware End of File = no
718 This will cause Bacula to use the MTFSF request to seek to the end of the
719 medium, and Bacula will keep track of the file number itself.
722 \label{IncorrectBlocks}
723 \subsection{Incorrect Number of Blocks or Positioning Errors}
724 \index[general]{Testing!Incorrect Number of Blocks or Positioning Errors}
725 \index[general]{Incorrect Number of Blocks or Positioning Errors}
727 {\bf Bacula's} preferred method of working with tape drives (sequential
728 devices) is to run in variable block mode, and this is what is set by default.
729 You should first ensure that your tape drive is set for variable block mode
732 If your tape drive is in fixed block mode and you have told Bacula to use
733 different fixed block sizes or variable block sizes (default), you will get
734 errors when Bacula attempts to forward space to the correct block (the kernel
735 driver's idea of tape blocks will not correspond to Bacula's).
737 All modern tape drives support variable tape blocks, but some older drives (in
738 particular the QIC drives) as well as the ATAPI ide-scsi driver run only in
739 fixed block mode. The Travan tape drives also apparently must run in fixed
740 block mode (to be confirmed).
742 Even in variable block mode, with the exception of the first record on the
743 second or subsequent volume of a multi-volume backup, Bacula will write blocks
744 of a fixed size. However, in reading a tape, Bacula will assume that for each
745 read request, exactly one block from the tape will be transferred. This the
746 most common way that tape drives work and is well supported by {\bf Bacula}.
748 Drives that run in fixed block mode can cause serious problems for Bacula if
749 the drive's block size does not correspond exactly to {\bf Bacula's} block
750 size. In fixed block size mode, drivers may transmit a partial block or
751 multiple blocks for a single read request. From {\bf Bacula's} point of view,
752 this destroys the concept of tape blocks. It is much better to run in variable
753 block mode, and almost all modern drives (the OnStream is an exception) run in
754 variable block mode. In order for Bacula to run in fixed block mode, you must
755 include the following records in the Storage daemon's Device resource
760 Minimum Block Size = nnn
761 Maximum Block Size = nnn
765 where {\bf nnn} must be the same for both records and must be identical to the
766 driver's fixed block size.
768 We recommend that you avoid this configuration if at all possible by using
769 variable block sizes.
771 If you must run with fixed size blocks, make sure they are not 512 bytes. This
772 is too small and the overhead that Bacula has with each record will become
773 excessive. If at all possible set any fixed block size to something like
774 64,512 bytes or possibly 32,768 if 64,512 is too large for your drive. See
775 below for the details on checking and setting the default drive block size.
777 To recover files from tapes written in fixed block mode, see below.
780 \subsection{Ensuring that the Tape Modes Are Properly Set -- {\bf Linux
782 \index[general]{Ensuring that the Tape Modes Are Properly Set -- Linux Only}
784 If you have a modern SCSI tape drive and you are having problems with the {\bf
785 test} command as noted above, it may be that some program has set one or more
786 of your SCSI driver's options to non-default values. For example, if your
787 driver is set to work in SysV manner, Bacula will not work correctly because
788 it expects BSD behavior. To reset your tape drive to the default values, you
789 can try the following, but {\bf ONLY} if you have a SCSI tape drive on a {\bf
795 mt -f /dev/nst0 rewind
796 mt -f /dev/nst0 stoptions buffer-writes async-writes read-ahead
800 The above commands will clear all options and then set those specified. None
801 of the specified options are required by Bacula, but a number of other options
802 such as SysV behavior must not be set. Bacula does not support SysV tape
803 behavior. On systems other than Linux, you will need to consult your {\bf mt}
804 man pages or documentation to figure out how to do the same thing. This should
805 not really be necessary though -- for example, on both Linux and Solaris
806 systems, the default tape driver options are compatible with Bacula.
807 On Solaris systems, you must take care to specify the correct device
808 name on the {\bf Archive device} directive. See above for more details.
810 You may also want to ensure that no prior program has set the default block
811 size, as happened to one user, by explicitly turning it off with:
815 mt -f /dev/nst0 defblksize 0
819 If you are running a Linux
820 system, and the above command does not work, it is most likely because you
821 have not loaded the appropriate {\bf mt} package, which is often called
822 {\bf mt\_st}, but may differ according to your distribution.
824 If you would like to know what options you have set before making any of the
825 changes noted above, you can now view them on Linux systems, thanks to a tip
826 provided by Willem Riede. Do the following:
831 mt -f /dev/nst0 stsetoptions 0
832 grep st0 /var/log/messages
836 and you will get output that looks something like the following:
840 kernel: st0: Mode 0 options: buffer writes: 1, async writes: 1, read ahead: 1
841 kernel: st0: can bsr: 0, two FMs: 0, fast mteom: 0, auto lock: 0,
842 kernel: st0: defs for wr: 0, no block limits: 0, partitions: 0, s2 log: 0
843 kernel: st0: sysv: 0 nowait: 0
847 Note, I have chopped off the beginning of the line with the date and machine
848 name for presentation purposes.
850 Some people find that the above settings only last until the next reboot, so
851 please check this otherwise you may have unexpected problems.
853 Beginning with Bacula version 1.35.8, if Bacula detects that you are running
854 in variable block mode, it will attempt to set your drive appropriately. All
855 OSes permit setting variable block mode, but some OSes do not permit setting
856 the other modes that Bacula needs to function properly.
859 \subsection{Tape Hardware Compression and Blocking Size}
860 \index[general]{Tape Hardware Compression and Blocking Size}
861 \index[general]{Size!Tape Hardware Compression and Blocking Size}
863 You should be able to verify the tape compression status with sysfs on Linux.
865 cat /sys/class/scsi_tape/nst0/default_compression
868 You can, turn it on by using (on Linux):
873 mt -f /dev/nst0 defcompression 1
877 and of course, if you use a zero instead of the one at the end, you will turn
880 If you have built the {\bf mtx} program in the {\bf depkgs} package, you can
881 use tapeinfo to get quite a bit of information about your tape drive even if
882 it is not an autochanger. This program is called using the SCSI control
883 device. On Linux for tape drive /dev/nst0, this is usually /dev/sg0, while on
884 FreeBSD for /dev/nsa0, the control device is often /dev/pass2. For example on
885 my DDS-4 drive (/dev/nst0), I get the following:
890 Product Type: Tape Drive
892 Product ID: 'C5713A '
901 Medium Type: Not Loaded
907 where the {\bf DataCompEnabled: yes} means that tape hardware compression is
908 turned on. You can turn it on and off (yes|no) by using the {\bf mt}
909 commands given above. Also, this output will tell you if the {\bf BlockSize}
910 is non-zero and hence set for a particular block size. Bacula is not likely to
911 work in such a situation because it will normally attempt to write blocks of
912 64,512 bytes, except the last block of the job which will generally be
913 shorter. The first thing to try is setting the default block size to zero
914 using the {\bf mt -f /dev/nst0 defblksize 0} command as shown above.
915 On FreeBSD, this would be something like: {\bf mt -f /dev/nsa0 blocksize 0}.
917 On some operating systems with some tape drives, the amount of data that
918 can be written to the tape and whether or not compression is enabled is
919 determined by the density usually the {\bf mt -f /dev/nst0 setdensity xxx} command.
920 Often {\bf mt -f /dev/nst0 status} will print out the current
921 density code that is used with the drive. Most systems, but unfortunately
922 not all, set the density to the maximum by default. On some systems, you
923 can also get a list of all available density codes with:
924 {\bf mt -f /dev/nst0 densities} or a similar {\bf mt} command.
925 Note, for DLT and SDLT devices, no-compression versus compression is very
926 often controlled by the density code. On FreeBSD systems, the compression
927 mode is set using {\bf mt -f /dev/nsa0 comp xxx} where xxx is the
928 mode you want. In general, see {\bf man mt} for the options available on
931 Note, some of the above {\bf mt} commands may not be persistent depending
932 on your system configuration. That is they may be reset if a program
933 other than Bacula uses the drive or, as is frequently the case, on reboot
936 If your tape drive requires fixed block sizes (very unusual), you can use the
941 Minimum Block Size = nnn
942 Maximum Block Size = nnn
946 in your Storage daemon's Device resource to force Bacula to write fixed size
947 blocks (where you sent nnn to be the same for both of the above records). This
948 should be done only if your drive does not support variable block sizes, or
949 you have some other strong reasons for using fixed block sizes. As mentioned
950 above, a small fixed block size of 512 or 1024 bytes will be very inefficient.
951 Try to set any fixed block size to something like 64,512 bytes or larger if
952 your drive will support it.
954 Also, note that the {\bf Medium Type} field of the output of {\bf tapeinfo}
955 reports {\bf Not Loaded}, which is not correct. As a consequence, you should
956 ignore that field as well as the {\bf Attached Changer} field.
958 To recover files from tapes written in fixed block mode, see below.
961 \subsection{Tape Modes on FreeBSD}
962 \index[general]{FreeBSD!Tape Modes on}
963 \index[general]{Tape Modes on FreeBSD}
965 On most FreeBSD systems such as 4.9 and most tape drives, Bacula should run
970 mt -f /dev/nsa0 seteotmodel 2
971 mt -f /dev/nsa0 blocksize 0
972 mt -f /dev/nsa0 comp enable
976 You might want to put those commands in a startup script to make sure your
977 tape driver is properly initialized before running Bacula, because
978 depending on your system configuration, these modes may be reset if a
979 program other than Bacula uses the drive or when your system is rebooted.
981 Then according to what the {\bf btape test} command returns, you will probably
982 need to set the following (see below for an alternative):
986 Hardware End of Medium = no
988 Backward Space Record = no
989 Backward Space File = no
990 Fast Forward Space File = no
995 Then be sure to run some append tests with Bacula where you start and stop
996 Bacula between appending to the tape, or use {\bf btape} version 1.35.1 or
997 greater, which includes simulation of stopping/restarting Bacula.
999 Please see the file {\bf platforms/freebsd/pthreads-fix.txt} in the main
1000 Bacula directory concerning {\bf important} information concerning
1001 compatibility of Bacula and your system. A much more optimal Device
1002 configuration is shown below, but does not work with all tape drives. Please
1003 test carefully before putting either into production.
1005 Note, for FreeBSD 4.10-RELEASE, using a Sony TSL11000 L100 DDS4 with an
1006 autochanger set to variable block size and DCLZ compression, Brian McDonald
1007 reports that to get Bacula to append correctly between Bacula executions,
1008 the correct values to use are:
1012 mt -f /dev/nsa0 seteotmodel 1
1013 mt -f /dev/nsa0 blocksize 0
1014 mt -f /dev/nsa0 comp enable
1022 Hardware End of Medium = no
1024 Backward Space Record = no
1025 Backward Space File = no
1026 Fast Forward Space File = yes
1031 This has been confirmed by several other people using different hardware. This
1032 configuration is the preferred one because it uses one EOF and no backspacing
1033 at the end of the tape, which works much more efficiently and reliably with
1036 Finally, here is a Device configuration that Danny Butroyd reports to work
1037 correctly with the Overland Powerloader tape library using LT0-2 and
1042 # Overland Powerloader LT02 - 17 slots single drive
1046 Archive Device = /dev/nsa0
1047 AutomaticMount = yes;
1049 RemovableMedia = yes;
1051 Changer Command = "/usr/local/sbin/mtx-changer %c %o %S %a %d"
1052 Changer Device = /dev/pass2
1054 Alert Command = "sh -c 'tapeinfo -f %c |grep TapeAlert|cat'"
1056 # FreeBSD Specific Settings
1057 Offline On Unmount = no
1058 Hardware End of Medium = no
1060 Backward Space Record = no
1061 Fast Forward Space File = no
1065 The following Device resource works fine with Dell PowerVault 110T and
1066 120T devices on both FreeBSD 5.3 and on NetBSD 3.0. It also works
1067 with Sony AIT-2 drives on FreeBSD.
1072 # FreeBSD/NetBSD Specific Settings
1073 Hardware End of Medium = no
1075 Backward Space Record = no
1076 Fast Forward Space File = yes
1082 On FreeBSD version 6.0, it is reported that you can even set
1083 Backward Space Record = yes.
1087 \subsection{Finding your Tape Drives and Autochangers on FreeBSD}
1088 \index[general]{FreeBSD!Finding Tape Drives and Autochangers}
1089 \index[general]{Finding Tape Drives and Autochangers on FreeBSD}
1091 On FreeBSD, you can do a {\bf camcontrol devlist} as root to determine what
1092 drives and autochangers you have. For example,
1096 undef# camcontrol devlist
1097 at scbus0 target 2 lun 0 (pass0,sa0)
1098 at scbus0 target 4 lun 0 (pass1,sa1)
1099 at scbus0 target 4 lun 1 (pass2)
1103 from the above, you can determine that there is a tape drive on {\bf /dev/sa0}
1104 and another on {\bf /dev/sa1} in addition since there is a second line for the
1105 drive on {\bf /dev/sa1}, you know can assume that it is the control device for
1106 the autochanger (i.e. {\bf /dev/pass2}). It is also the control device name to
1107 use when invoking the tapeinfo program. E.g.
1111 tapeinfo -f /dev/pass2
1117 \subsection{Using the OnStream driver on Linux Systems}
1118 \index[general]{Using the OnStream driver on Linux Systems}
1119 \index[general]{Systems!Using the OnStream driver on Linux}
1121 Bacula version 1.33 (not 1.32x) is now working and ready for testing with the
1122 OnStream kernel osst driver version 0.9.14 or above. Osst is available from:
1123 \elink{http://sourceforge.net/projects/osst/}{http://sourceforge.net/projects/osst/}.
1125 To make Bacula work you must first load the new driver then, as root, do:
1129 mt -f /dev/nosst0 defblksize 32768
1133 Also you must add the following to your Device resource in your Storage
1138 Minimum Block Size = 32768
1139 Maximum Block Size = 32768
1143 Here is a Device specification provided by Michel Meyers that is known to
1149 Name = "Onstream DI-30"
1150 Media Type = "ADR-30"
1151 Archive Device = /dev/nosst0
1152 Minimum Block Size = 32768
1153 Maximum Block Size = 32768
1154 Hardware End of Medium = yes
1156 Backward Space File = yes
1157 Fast Forward Space File = yes
1159 AutomaticMount = yes
1161 Removable Media = yes
1166 \section{Hardware Compression on EXB-8900}
1167 \index[general]{Hardware Compression on EXB-8900}
1168 \index[general]{EXB-8900!Hardware Compression}
1170 To active, check, or disable the hardware compression feature
1171 on an EXB-8900, use the exabyte MammothTool. You can get it here:
1172 \elink{http://www.exabyte.com/support/online/downloads/index.cfm}{http://www.exabyte.com/support/online/downloads/index.cfm}.
1173 There is a Solaris version of this tool. With option -C 0 or 1 you
1174 can disable or activate compression. Start this tool without any
1175 options for a small reference.
1178 \subsection{Using btape to Simulate Filling a Tape}
1179 \index[general]{Using btape to Simulate Filling a Tape}
1180 \index[general]{Tape!Using btape to Simulate Filling}
1182 Because there are often problems with certain tape drives or systems when end
1183 of tape conditions occur, {\bf btape} has a special command {\bf fill} that
1184 causes it to write random data to a tape until the tape fills. It then writes
1185 at least one more Bacula block to a second tape. Finally, it reads back both
1186 tapes to ensure that the data has been written in a way that Bacula can
1187 recover it. Note, there is also a single tape option as noted below, which you
1188 should use rather than the two tape test. See below for more details.
1190 This can be an extremely time consuming process (here it is about 6 hours) to
1191 fill a full tape. Note, that btape writes random data to the tape when it is
1192 filling it. This has two consequences: 1. it takes a bit longer to generate
1193 the data, especially on slow CPUs. 2. the total amount of data is
1194 approximately the real physical capacity of your tape, regardless of whether
1195 or not the tape drive compression is on or off. This is because random data
1196 does not compress very much.
1198 To begin this test, you enter the {\bf fill} command and follow the
1199 instructions. There are two options: the simple single tape option and the
1200 multiple tape option. Please use only the simple single tape option because
1201 the multiple tape option still doesn't work totally correctly. If the single
1202 tape option does not succeed, you should correct the problem before using
1204 \label{RecoveringFiles}
1206 \section{Recovering Files Written With Fixed Block Sizes}
1207 \index[general]{Recovering Files Written With Fixed Block Sizes}
1209 If you have been previously running your tape drive in fixed block mode
1210 (default 512) and Bacula with variable blocks (default), then in version
1211 1.32f-x and 1.34 and above, Bacula will fail to recover files because it does
1212 block spacing, and because the block sizes don't agree between your tape drive
1213 and Bacula it will not work.
1215 The long term solution is to run your drive in variable block mode as
1216 described above. However, if you have written tapes using fixed block sizes,
1217 this can be a bit of a pain. The solution to the problem is: while you are
1218 doing a restore command using a tape written in fixed block size, ensure that
1219 your drive is set to the fixed block size used while the tape was written.
1220 Then when doing the {\bf restore} command in the Console program, do not
1221 answer the prompt {\bf yes/mod/no}. Instead, edit the bootstrap file (the
1222 location is listed in the prompt) using any ASCII editor. Remove all {\bf
1223 VolBlock} lines in the file. When the file is re-written, answer the question,
1224 and Bacula will run without using block positioning, and it should recover
1228 \section{Tape Blocking Modes}
1229 \index[general]{Modes!Tape Blocking}
1230 \index[general]{Tape Blocking Modes}
1232 SCSI tapes may either be written in {\bf variable} or {\bf fixed} block sizes.
1233 Newer drives support both modes, but some drives such as the QIC devices
1234 always use fixed block sizes. Bacula attempts to fill and write complete
1235 blocks (default 65K), so that in normal mode (variable block size), Bacula
1236 will always write blocks of the same size except the last block of a Job. If
1237 Bacula is configured to write fixed block sizes, it will pad the last block of
1238 the Job to the correct size. Bacula expects variable tape block size drives to
1239 behave as follows: Each write to the drive results in a single record being
1240 written to the tape. Each read returns a single record. If you request less
1241 bytes than are in the record, only those number of bytes will be returned, but
1242 the entire logical record will have been read (the next read will retrieve the
1243 next record). Thus data from a single write is always returned in a single
1244 read, and sequentially written records are returned by sequential reads.
1246 Bacula expects fixed block size tape drives to behave as follows: If a write
1247 length is greater than the physical block size of the drive, the write will be
1248 written as two blocks each of the fixed physical size. This single write may
1249 become multiple physical records on the tape. (This is not a good situation).
1250 According to the documentation, one may never write an amount of data that is
1251 not the exact multiple of the blocksize (it is not specified if an error
1252 occurs or if the the last record is padded). When reading, it is my
1253 understanding that each read request reads one physical record from the tape.
1254 Due to the complications of fixed block size tape drives, you should avoid
1255 them if possible with Bacula, or you must be ABSOLUTELY certain that you use
1256 fixed block sizes within Bacula that correspond to the physical block size of
1257 the tape drive. This will ensure that Bacula has a one to one correspondence
1258 between what it writes and the physical record on the tape.
1260 Please note that Bacula will not function correctly if it writes a block and
1261 that block is split into two or more physical records on the tape. Bacula
1262 assumes that each write causes a single record to be written, and that it can
1263 sequentially recover each of the blocks it has written by using the same
1264 number of sequential reads as it had written.
1266 \section{Details of Tape Modes}
1267 \index[general]{Modes!Details}
1268 \index[general]{Details of Tape Modes}
1269 Rudolf Cejka has provided the following information concerning
1270 certain tape modes and MTEOM.
1274 It is always possible to position filemarks or blocks, whereas
1275 positioning to the end-of-data is only optional feature, however it is
1276 implemented very often. SCSI specification also talks about optional
1277 sequential filemarks, setmarks and sequential setmarks, but these are not
1278 implemented so often. Modern tape drives keep track of file positions in
1279 built-in chip (AIT, LTO) or at the beginning of the tape (SDLT), so there
1280 is not any speed difference, if end-of-data or filemarks is used (I have
1281 heard, that LTO-1 from all 3 manufacturers do not use its chip for file
1282 locations, but a tape as in SDLT case, and I'm not sure about LTO-2 and
1283 LTO-3 case). However there is a big difference, that end-of-data ignores
1284 file position, whereas filemarks returns the real number of skipped
1285 files, so OS can track current file number just in filemarks case.
1288 Solaris does use just SCSI SPACE Filemarks, it does not support SCSI
1289 SPACE End-of-data. When MTEOM is called, Solaris does use SCSI SPACE
1290 Filemarks with count = 1048576 for fast mode, and combination of SCSI
1291 SPACE Filemarks with count = 1 with SCSI SPACE Blocks with count = 1 for
1292 slow mode, so EOD mark on the tape on some older tape drives is not
1293 skipped. File number is always tracked for MTEOM.
1295 Linux does support both SCSI SPACE Filemarks and End-of-data: When MTEOM
1296 is called in MT\_ST\_FAST\_MTEOM mode, SCSI SPACE End-of-data is used.
1297 In the other case, SCSI SPACE Filemarks with count =
1299 There is no real slow mode like in Solaris - I just expect, that for
1300 older tape drives Filemarks may be slower than End-of-data, but not so
1301 much as in Solaris slow mode. File number is tracked for MTEOM just
1302 without MT\_ST\_FAST\_MTEOM - when MT\_ST\_FAST\_MTEOM is used, it is not.
1304 FreeBSD does support both SCSI SPACE Filemarks and End-of-data, but when
1305 MTEOD (MTEOM) is called, SCSI SPACE End-of-data is always used. FreeBSD
1306 never use SCSI SPACE Filemarks for MTEOD. File number is never tracked
1310 When {\bf Hardware End of Medium = Yes} is used, MTEOM is called, but it
1311 does not mean, that hardware End-of-data must be used. When Hardware End
1312 of Medium = No, if Fast Forward Space File = Yes, MTFSF with count =
1313 32767 is used, else Block Read with count = 1 with Forward Space File
1314 with count = 1 is used, which is really very slow.
1316 \item [Hardware End of Medium = Yes|No]
1317 The name of this option is misleading and is the source of confusion,
1318 because it is not the hardware EOM, what is really switched here.
1320 If I use Yes, OS must not use SCSI SPACE End-of-data, because Bacula
1321 expects, that there is tracked file number, which is not supported by
1322 SCSI specification. Instead, the OS have to use SCSI SPACE Filemarks.
1324 If I use No, an action depends on Fast Forward Space File.
1326 When I set {\bf Hardware End of Medium = no}
1327 and {\bf Fast Forward Space File = no}
1328 file positioning was very slow
1329 on my LTO-3 (about ten to 100 minutes), but
1331 with {\bf Hardware End of Medium = no} and
1332 {\bf Fast Forward Space File = yes}, the time is ten to
1333 100 times faster (about one to two minutes).
1337 \section{Tape Performance Problems}
1338 \index[general]{Tape Performance}
1339 If you have LTO-3 or LTO-4 drives, you should be able to
1340 fairly good transfer rates; from 60 to 150 MB/second, providing
1341 you have fast disks; GigaBit Ethernet connections (probably 2); you are
1342 running multiple simultaneous jobs; you have Bacula data spooling
1343 enabled; your tape block size is set to 131072 or 262144; and
1344 you have set {\bf Maximum File Size = 5G}.
1346 If you are not getting good performance, consider some of the following
1347 suggestions from the Allen Balck on the Bacula Users email list:
1350 \item You are using an old HBA (i.e. SCSI-1, which only does 5 MB/s)
1352 \item There are other, slower, devices on the SCSI bus. The HBA will
1353 negotiate the speed of every device down to the speed of the
1356 \item There is a termination problem on the bus (either too much or
1357 too little termination). The HBA will drop the bus speed in an
1358 attempt to increase the reliability of the bus.
1360 \item Loose or damaged cabling - this will probably make the HBA "think"
1361 you have a termination problem and it will react as in 3 above.
1364 See if /var/adm/messages (or /var/log/messages) tells you what the sync
1365 rate of the SCSI devices/bus are. Also, the next time you reboot, the
1366 BIOS may be able to tell you what the rate of each device is.
1369 \section{Autochanger Errors}
1370 \index[general]{Errors!Autochanger}
1371 \index[general]{Autochanger Errors}
1373 If you are getting errors such as:
1377 3992 Bad autochanger "load slot 1, drive 1": ERR=Child exited with code 1.
1381 and you are running your Storage daemon as non-root, then most likely
1382 you are having permissions problems with the control channel. Running
1383 as root, set permissions on /dev/sgX so that the userid and group of
1384 your Storage daemon can access the device. You need to ensure that you
1385 all access to the proper control device, and if you don't have any
1386 SCSI disk drives (including SATA drives), you might want to change
1387 the permissions on /dev/sg*.
1389 \section{Syslog Errors}
1390 \index[general]{Errors!Syslog}
1391 \index[general]{Syslog Errors}
1393 If you are getting errors such as:
1397 : kernel: st0: MTSETDRVBUFFER only allowed for root
1401 you are most likely running your Storage daemon as non-root, and
1402 Bacula is attempting to set the correct OS buffering to correspond
1403 to your Device resource. Most OSes allow only root to issue this
1404 ioctl command. In general, the message can be ignored providing
1405 you are sure that your OS parameters are properly configured as
1406 described earlier in this manual. If you are running your Storage daemon
1407 as root, you should not be getting these system log messages, and if
1408 you are, something is probably wrong.