Re: End of tape errors
Originally, we had the tape settings to high, allowing the DLT 7000 drive with DLT IV tapes, 34,000 megs with a filemark of 8k. ... Those numbers seem reasonable. Why do you think they are too high? Are you using hardware compression (put a different way, what device name are you using for the tape drive)? Are you using software compression? I considered these numbers too high because of the end of tape errors. The magic word assume factors in there, but I don't want to say it out loud. The tape device I am using is 0lbn. We are using software compression on the dumps. That began to fail when the amount of data reached a significant size. ... What do you mean by significant? The original number of disks and volume of information we were archiving was small, so no errors, when we started adding more disks, the system eventually began showing problems. significant was around 40 gigs, ie around 20 compressed. We got the traditional *** A TAPE ERROR OCCURRED: [[writing file: short write]]. The filemark was killing us as was the length of the tape. The filemark and length of tape values are **only** used by Amanda to do the estimates. Once the actual backups start, Amanda keeps writing until it gets an error. So when it reported the short write, that's exactly what it meant -- you banged into physical end of tape. There should have been a line something like this in the NOTES section: taper: tape 041138/champion kb 43321088 fm 34 writing file: short write --- Our last short dump line: taper: tape VOL2 kb 19915968 fm 99 writing file: short write So, we ran the tapetype program and got a new tape size of 19,457 megs. Now this has failed us with a short write. That looks like you used the wrong density or forced it on the front panel. What device name did you use? Did you make certain the tape mounted at 35.0 GByte density? -- The device name we use is /dev/nrst1. As for the tape mounting at 35.0 gig density, I did not consider any change in it since Amanda was mounting the tape (again, the tricky word assume creeps in) Michael Campfield
Re: End of tape errors
The tape device I am using is 0lbn. We are using software compression on the dumps. That's probably not the right device name to get 35 GBytes on a DLT-IV tape with a DLT7000 drive. You should be using 0hn (drop the 'b' -- it will lead you down a dark path). Assuming you have not messed with /kernel/drv/st.conf, the default settings for a DLT7000 are in DLT7k-data: DLT7k-data = 1,0x38,0,0x1D639,4,0x82,0x83,0x84,0x85,2; The last four hex values (0x82,0x83,0x84,0x85) specify the density code sent to the drive when you use (respectively) 'l', 'm', 'h' and 'u' (or 'c') in the device name. Looking at a DLT7000 manual, 0x84 sets the drive to 35 GBytes, no compression, so you want the 'h' name. ... significant was around 40 gigs, ie around 20 compressed. You're actually getting 2:1 compression? That's a borderline miracle :-). Our last short dump line: taper: tape VOL2 kb 19915968 fm 99 writing file: short write This matches perfectly with above. You got 20 GBytes on a tape, which is what the 'l' density code (0x82) told the drive to do. The device name we use is /dev/nrst1. ... I'm confused. I thought you said you used 0lbn? In any case, I recommend you change it to /dev/rmt/0hn. It's not 100% clear whether DLT7000 drives (possibly in conjunction with the Solaris st driver) will properly switch to a new density just by using the different name. They *should*, since the tape is rewritten from BOT, but I seem to recall having some trouble. Try just changing the device name, then look at the taper line in your next report. If it shows more than 20 GBytes written, you're all set. If it does not, you're going to have to force the issue on each mount via the front panel until all the tapes get rewritten once (sigh). As for the tape mounting at 35.0 gig density, I did not consider any change in it since Amanda was mounting the tape (again, the tricky word assume creeps in) Amanda may have mounted the tape, but you're the one who told it how to do it :-). Michael Campfield John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: End of tape errors
Did you add those patches ??? 111972-02 112068-01 Chamby - Original Message - From: Michael P Campfield [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, January 24, 2002 10:10 AM Subject: End of tape errors Hello all. We have been experiencing some very strange errors on our Sun StorEdge L20 system and were wondering if anyone had similar problems or knew of a solution. Originally, we had the tape settings to high, allowing the DLT 7000 drive with DLT IV tapes, 34,000 megs with a filemark of 8k. That began to fail when the amount of data reached a significant size. We got the traditional *** A TAPE ERROR OCCURRED: [[writing file: short write]]. The filemark was killing us as was the length of the tape. So, we ran the tapetype program and got a new tape size of 19,457 megs. Now this has failed us with a short write. The only thing different from the tapetype suggestion is that we changed the filemark from 0 to 2024 kbytes. Is my filemark issue the problem or is something sinister afoot? Michael Campfield Labstaff Computer Science Department University of Tennessee, Knoxville
Re: End of tape errors
Originally, we had the tape settings to high, allowing the DLT 7000 drive with DLT IV tapes, 34,000 megs with a filemark of 8k. ... Those numbers seem reasonable. Why do you think they are too high? Are you using hardware compression (put a different way, what device name are you using for the tape drive)? Are you using software compression? That began to fail when the amount of data reached a significant size. ... What do you mean by significant? We got the traditional *** A TAPE ERROR OCCURRED: [[writing file: short write]]. The filemark was killing us as was the length of the tape. The filemark and length of tape values are **only** used by Amanda to do the estimates. Once the actual backups start, Amanda keeps writing until it gets an error. So when it reported the short write, that's exactly what it meant -- you banged into physical end of tape. There should have been a line something like this in the NOTES section: taper: tape 041138/champion kb 43321088 fm 34 writing file: short write This tells you *exactly* how much data had been written when the OS returned the error (43321088 KBytes - ~41.3 GBytes in the example). So, we ran the tapetype program and got a new tape size of 19,457 megs. Now this has failed us with a short write. That looks like you used the wrong density or forced it on the front panel. What device name did you use? Did you make certain the tape mounted at 35.0 GByte density? The only thing different from the tapetype suggestion is that we changed the filemark from 0 to 2024 kbytes. As above, that would only affect how much Amanda had to work with to do the estimates. It would have nothing to do with actually writing to the tape. Michael Campfield John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
