Re: end-of-tape error
Okay, I just ran amdump manually, with much the same result (one large partition results in an end-of-tape message in the Amanda report, but it looks like something else is really going on). Here's what I found in /var/log/messages. I believe "sense key" means the system (st()?) asked the drive what was up and got a response... but I don't really understand the response: Jun 26 16:11:34 agrippa kernel: st0: Error with sense data: Info fld=0x0, Deferred st09:00: sense key Medium Error Jun 26 16:11:34 agrippa kernel: Additional sense indicates Logical unit communication time-out Jun 26 16:11:34 agrippa kernel: st0: Error with sense data: Info fld=0x0, Deferred st09:00: sense key Medium Error Jun 26 16:11:34 agrippa kernel: Additional sense indicates Logical unit communication time-out Jun 26 16:11:34 agrippa kernel: st0: Error on write filemark. Jun 26 16:11:34 agrippa sendbackup[31899]: index tee cannot write [Connection reset by peer] This would seem to indicate that scsi tape 0 is messing up. Which makes sense since it's the only one I have. However, I am pointing the whole amanda operation at /dev/nst0 and not /dev/st0, since nst0 (I believe) is the non-rewinding device 'connection'. Am I wrong to assume that? Could there be some other parameter that I've screwed up? :) Here's the relevant line from the Notes section of the repoort, in case it helps... taper: tape DailySet1-14 kb 5070592 fm 6 writing file: Input/output error Is there documentation on what the fields are in this note? It /appears/ to mean that it wrote just about 5 GB... does the fm 6 mean 'file mark 6' maybe? Last time it was fm 4, with about 300 MB more written. Once again, thanks a million for your help so far, guys. I really appreciate it. Jesse On Wed, 26 Jun 2002 10:51:43 -0400 (EDT) "Joshua Baker-LePain" <[EMAIL PROTECTED]> wrote: > On Wed, 26 Jun 2002 at 10:13am, Jesse Griffis wrote > > > I am getting an odd end-of-tape error on every tape, every time I try > > to write a very large file. Below is the Amanda report for the last > > attempt I tried. I'm chopping out some of the extraneous detail (the > > > > > These dumps were to tape DailySet1-17. > > *** A TAPE ERROR OCCURRED: [[writing file: Input/output error]]. > > Note that here amanda is just telling you what the OS told it. For more > detail on exactly what sort of I/O error occurred, look in > /var/log/messages. > > > Tape Time (hrs:min)0:12 0:12 0:00 > > Tape Size (meg) 4590.4 4590.40.0 > > Tape Used (%) 7.77.70.0 > > Filesystems Taped 3 3 0 > > Avg Tp Write Rate (k/s) 6776.7 6776.7-- > > In here there should be a NOTES section. That will tell you *exactly* how > > much data got to tape before the I/O error. As Jon mentioned, make sure > that you're not using hardware compressions, as you are using software > compression. > > -- > Joshua Baker-LePain > Department of Biomedical Engineering > Duke University > > > > >
Re: end-of-tape error
On Wed, Jun 26, 2002 at 12:14:12PM -0400, Jesse Griffis wrote: > taper: tape DailySet1-17 kb 5373824 fm 4 writing file: Input/output error > > Does this mean that it only managed to write 5 MB before the I/O error? No, I think that is in KB, so 5.37 GB was written at the time of the error. I think the difference in that number and the earlier part of the report, 4.59 GB is that the smaller number is "successfully written", i.e. complete dumps while the larger is total written including the incomplete dump in progress at the time of the error. > > I don't see anything in /var/log/messages around the time of this backup, so > I suppose > I'll have to run another with the express purpose of hunting for fresh log > results... :) I think that is the proper approach. You seem to have most other bases covered. Sounds like some form of hardware situation (head cleaning, cableing, terminator, ...) Look for scsi messages too. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: end-of-tape error
First, Jon, sorry about the long lines. In 10 years I never heard of an
email client
that didn't at least wrap long lines, if not automatically adding newlines.
I'll try
to be more careful.
Next, Joshua, the NOTES section, I missed that one, sorry. Here it is:
===
NOTES:
planner: Last full dump of localhost://ptolemy/user1 on tape overwritten
in 1 run.
planner: Last full dump of localhost://ptolemy/user2 on tape overwritten
in 1 run.
planner: Adding new disk localhost://cassini/d.
planner: Adding new disk localhost://peisin/c$.
planner: Adding new disk localhost://peisin/d$.
taper: tape DailySet1-17 kb 5373824 fm 4 writing file: Input/output error
driver: going into degraded mode because of tape error.
Does this mean that it only managed to write 5 MB before the I/O error?
I don't see anything in /var/log/messages around the time of this backup, so
I suppose
I'll have to run another with the express purpose of hunting for fresh log
results... :)
As for tape capacity, the 225m AME tapes (exabyte brand) we're using w/ the
Mammoth-2 drive are rated for 60 GB Uncompressed. Based mainly on the
FAQ-o-Matic, my tapetype entry is this:
define tapetype EXB-M2 {
comment "Exabyte M2 drive"
length 6 mbytes
filemark 200 kbytes
speed 3300 kbytes
}
I have no idea if that is 100% correct, however: The tapetype program that
comes
with the source gives me different results (and very very large filemark
numbers)
every time I run it.
As for hardware compression, I have it turned off. Here is a copy of the
dump file
generated by M2Monitor, Exabyte's monitoring tool for the Mammoth-2 drives:
Buffered Mode = BUFFERED
Data Compression Enable = OFF
Diagnostics: Tape History Log = DISABLE
Disconnect Control = 0x08
Modify Data Pointers = OFF
Disconnect Immediate = ON
Disconnect = NORMAL
Gap Threshold = 0x00
Logical Block Size = 0x0400
Maximum Burst Length = 0x
Mode Sense: Default Density = OFF
Motion Threshold = 0x80
Operator: Button Operation = WAIT_DONE
Operator: Cleaning Mode = LIGHTS
Operator: LCD Language = ENGLISH
Product Identification = Mammoth2
Reporting Modes = 0x60
Setmark Option = ON
Early Warning Option = OFF
Request Sense: Clearing Sense Data = CLEAR
Request Sense: EOM bit at LBOP = OFF
SCSI: Command Queuing = NORMAL
SCSI: Parity Error Handling = FAIL_RW
SCSI: Synchronous Negotiation = RECEIVE
SmartClean Mode = CLEAN_NORMAL
Write Delay Time = 0x
I don't know what a lof of that stuff means, but I can see that compression
is turned off... :P
Finally, if there's an ability to contribute to the Amanda project in some
way (probably monetarily, because as might be abundantly clear, I'm no
device programmer...), can someone point me to a link?
Thanks for your help, Jon and Joshua.
Jesse
> On Wed, 26 Jun 2002 at 10:13am, Jesse Griffis wrote
>
> > I am getting an odd end-of-tape error on every tape, every time I try
> > to write a very large file. Below is the Amanda report for the last
> > attempt I tried. I'm chopping out some of the extraneous detail (the
>
> >
> > These dumps were to tape DailySet1-17.
> > *** A TAPE ERROR OCCURRED: [[writing file: Input/output error]].
>
> Note that here amanda is just telling you what the OS told it. For more
> detail on exactly what sort of I/O error occurred, look in
> /var/log/messages.
>
> > Tape Time (hrs:min)0:12 0:12 0:00
> > Tape Size (meg) 4590.4 4590.40.0
> > Tape Used (%) 7.77.70.0
> > Filesystems Taped 3 3 0
> > Avg Tp Write Rate (k/s) 6776.7 6776.7--
>
> In here there should be a NOTES section. That will tell you *exactly* how
>
> much data got to tape before the I/O error. As Jon mentioned, make sure
> that you're not using hardware compressions, as you are using software
> compression.
>
> --
> Joshua Baker-LePain
> Department of Biomedical Engineering
> Duke University
>
>
>
>
>
Re: end-of-tape error
On Wed, 26 Jun 2002 at 10:13am, Jesse Griffis wrote > I am getting an odd end-of-tape error on every tape, every time I try > to write a very large file. Below is the Amanda report for the last > attempt I tried. I'm chopping out some of the extraneous detail (the > > These dumps were to tape DailySet1-17. > *** A TAPE ERROR OCCURRED: [[writing file: Input/output error]]. Note that here amanda is just telling you what the OS told it. For more detail on exactly what sort of I/O error occurred, look in /var/log/messages. > Tape Time (hrs:min)0:12 0:12 0:00 > Tape Size (meg) 4590.4 4590.40.0 > Tape Used (%) 7.77.70.0 > Filesystems Taped 3 3 0 > Avg Tp Write Rate (k/s) 6776.7 6776.7-- In here there should be a NOTES section. That will tell you *exactly* how much data got to tape before the I/O error. As Jon mentioned, make sure that you're not using hardware compressions, as you are using software compression. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: end-of-tape error
On Wed, Jun 26, 2002 at 10:13:32AM -0400, Jesse Griffis wrote: > Hello, > > Briefly, I have an Exabyte EZ-17 with a Mammoth-2 drive inside. I'm running it on a >dual-CPU RedHat 7.2 server with plenty of RAM and a holding disk around 25 GB (I can >certainly provide more detail when / if needed). > > I've been able to figure out 99% of the Amanda process (some trial and error, lots >of research on this list, among other good web sites out there), but I'm stuck now, >and the boss is about to make me go spend a thousand bucks on Veritas' or someone >else's... > > I am getting an odd end-of-tape error on every tape, every time I try to write a >very large file. Below is the Amanda report for the last attempt I tried. I'm >chopping out some of the extraneous detail (the STRANGE results on some of the drives >is from NT machines, files with odd characters, thanks to Word). Can someone explain >why 7.7% used tape would give me an out-of-tape error? On the holding disk, the >/home partition is about 4.6 GB and there is much space remaining (10 GB right now, >even though there are numerous holdings stuck there for the moment...) > breaking up long lines with would be appreciated by some of us. > Any help at all would be greatly appreciated! 7.7% is probably a calculated value based on your tapetype setting. You don't show that. What do you claim is the capacity of your tape? Are you be claiming 60GB? That is 4.59GB / 0.077. Is that valid for your drive and tape combination? Are you using (perhaps unknowingly) hardware compression? That should never be used in combination with the software compression you are using. -- Jon H. LaBadie [EMAIL PROTECTED] JG Computing 4455 Province Line Road(609) 252-0159 Princeton, NJ 08540-4322 (609) 683-7220 (fax)
