Tape Input-Output error: Difference between revisions

From wiki.zmanda.com
Jump to navigation Jump to search
m (up link)
(reworking to be more descriptive)
 
(7 intermediate revisions by 3 users not shown)
Line 1: Line 1:
--- This text was originally contributed to the  AMANDA-FAQ-O-Matic by [email protected]. ---
{{Troubleshooting Header}}
=Problem=


Why does AMANDA keep on giving "Tape I/O" error for the amdump and amflush program? It always works for amcheck on new tapes (failing on reused tapes), and amlabel always works too. This leads me to believe that my 24 tapes in my cycle are still good, as well as the tape drive itself. What could it be?
{{man|8|amdump}} and {{man|8|amflush}}, or any application accessing the tape drive, give "Input/output error" messages, such as.  
   taper: tape weekly-002 kb 0 fm 0 writing filemark: Input/output error
   taper: tape weekly-002 kb 0 fm 0 writing filemark: Input/output error
=Solution=
Most in-kernel tape device drivers do not provide very detailed errors back to an applications.  Often EIO ("Input/output error") is the catch-all "something went wrong" indication.  This can indicate something benign like end-of-tape, or more serious problems such as a failing tape drive (see [[How To:Diagnose a Failing Tape Drive]]), bad cabling, or even a hapless operator removing a tape from a running drive.


 
Amanda ''guesses'' how large a dump will be, and uses the "length" parameter as an estimate of tape size. The dump estimate can change on a system in constant use, and tape cartridges can contain a bit more or less tape than advertized (due to stretch, etc.). So sometimes Amanda, despite its best intentions, writes off the end of a tape.  When this happens, you will often see a message like "Input/output error," and in this case the error is fairly benign -- Amanda will keep the dump on the holding disk (you '''do''' have a holding disk, right?) and flush it to tape on the next amflush or, if you have "autoflush yes", on the next amdump run.
I think I found out the problem for me, and maybe this will help others.
First of all, amdump "GUESSES" how large a dump will be. This can change on a system in constant use (good time to perform remote dumps is durring scheduled downtime). So the major problem is that amdump will figure out what it has room for durring the dump, and if it 'accidently' exceeds that amount, you'll get a  
  /dev/tape error input/output
There are other factors involved here, so don't rule out the obvious.
My drive was involved in a lightning storm and hadn't worked well since. I tested it by rebooting my system (to make sure everything was clean), then I used the following commands to diagnose my drive after I put a unimportant and supposedly good tape in the drive
 
  mt rewind
  mt setblk 0
  tar -cpvf /dev/nst0 /home/loodwig
  mkdir /home/loodwig/dummy
  cd /home/loodwig/dummy
  mt rewind
  tar -xpvf /dev/nst0
 
tried this 5 times.
3 times it gave i/o errors, meaning the drive was junk.
Replacement drive gives occasional errors, but the gab is that the same tape will work in the future, amflush works on putting the 'degraded' dumps elsewhere, and adjusting the tapesize to something smaller (turned a 7gb to a 6.5) in the tape type field in amanda.conf will reduce the occurance of the error. Just make sure your temporary holding space can hold a FULL DUMP and then some (I do 6.5 gb dumps, and a 10gb scsi partition for backups alone). Worse case scenario, you have at least 1 night's backup on your hard drive for those users who magically erase directories on a whim (provided you don't need old data, this is a nice temporary fix).
 
Another thing to note also is how long does it take to fail, if it fails if part of the tape gets written, and then it 'broken-pipe's or 'i/o error's on you, then the drive is probably just dirty
if it fails right away, check controller cards, cables, connections, kernel support, etc
 
If it reads but wont write, or writes but wont read then you probably have what I had... a bad head (tape head :). Call your company, and hope it's under warranty.
 
----
See more [[amdump issues]].

Latest revision as of 16:38, 18 August 2008

This article is a part of the Troubleshooting collection.

Problem

amdump(8) and amflush(8), or any application accessing the tape drive, give "Input/output error" messages, such as. 

  taper: tape weekly-002 kb 0 fm 0 writing filemark: Input/output error

Solution

Most in-kernel tape device drivers do not provide very detailed errors back to an applications. Often EIO ("Input/output error") is the catch-all "something went wrong" indication. This can indicate something benign like end-of-tape, or more serious problems such as a failing tape drive (see How To:Diagnose a Failing Tape Drive), bad cabling, or even a hapless operator removing a tape from a running drive.

Amanda guesses how large a dump will be, and uses the "length" parameter as an estimate of tape size. The dump estimate can change on a system in constant use, and tape cartridges can contain a bit more or less tape than advertized (due to stretch, etc.). So sometimes Amanda, despite its best intentions, writes off the end of a tape. When this happens, you will often see a message like "Input/output error," and in this case the error is fairly benign -- Amanda will keep the dump on the holding disk (you do have a holding disk, right?) and flush it to tape on the next amflush or, if you have "autoflush yes", on the next amdump run.

Retrieved from ‘http://wiki.zmanda.com/index.php?title=Tape_Input-Output_error&oldid=6226’