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.
