>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]
