“waits till 6 tapes are full before a problem” and “errors on amrmtape”
While I didn’t think amrmtape actually touched the tape (merely the files containing amanda’s memory), it kinda sounds like your tape drive can write, but not over-write. Dunno if that’s a useful point to tell your repair team? Deb Baddorf > On Oct 24, 2018, at 12:57 PM, Chris Nighswonger > <[email protected]> wrote: > > On Wed, Oct 24, 2018 at 12:04 PM Jean-Francois Malouin > <[email protected]> wrote: >> >> * Chris Nighswonger <[email protected]> [20181024 10:25]: >>> Any thoughts on what's going on here? I thought running amlabel -f >>> forced deletion of any amanda volumes on that tape? >> >> The '-f' flag forces amlabel to write a label even if something is detected >> at >> the beginnning of the tape, and does nothing else to the tape. >> > > I see that in the man page now. I was reading way too fast. :P > >> Are you sure your hardware is healthy? >> > > Brand new hardware. It was just replaced by Quantum two months ago. > FWIW, this is the third replacement during our four-year support > contract with them. Soooo.... I headed over to xTalk and got the > following results which are really no surprise given the track record > of Quantum: > > =================================================================== > xTalk Management Console Wizard: User selections > =================================================================== > Device entered ->/dev/sg3<- > Script entered ->SCSI_Interconnect.xcs<- > =================================================================== > > Press 'Enter' when ready to continue or Ctrl-C to cancel: > > Phase 1 : Collection... > Loading: ./Scripts//SCSI_Interconnect.xcs > Complete... > Phase 1 Completed. > Phase 2 : Validation... > Phase 2 Complete. > Phase 3 : Linking... > Symbols Link Complete... > Uninitialized Variable Scan Complete... > Vector Linking Complete... > Phase 3 Complete. > ____________________________________________________________ > > SCSI Interconnect Test > Sense: CC: 0B ASC: 47 ASCQ: 03 = "Informational unit CRC failure." > VS Sense: 0 > Catagory: N/A > Details: No error > Writing Problem Detected > Problem Detected > =================================================================== > > So it looks like its off to open yet another rapid replacement request. > > Of course, this begs the question: Why do the backups run fine until > the first 6 tapes are full and then start borking? > >> Also, a blocksize of 32k (default value) might not give you the best >> performance. My experiments over the years suggest to err on much bigger >> values, 512k and more for LTO5 and 6 seem reasonable in my local environment. > > Thanks. I have adjusted accordingly. We'll see how it goes. Any > performance improvement is very much welcomed. > > Interestingly enough, running amrmtape --erase results in an error > stating the device does not support this feature.
