[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Where is the problem: Tape Drive? Cartridge(s)? Cable? SAS Controller?



On Thursday 02 January 2020 12:13:43 Dan Ritter wrote:

> Jack G F Hill wrote:
> > All this leads to the hardware question, "What is failing": Tape
> > Drive? Cartridge(s)? Cable? SAS Controller?
> >
> > Rather than just blindly substitute parts (expensive, time
> > consuming, frustratingly inconclusive) and try to eliminate that
> > way, I'd really like to have a better roadmap for locating the
> > issue. A new SAS Controller, or the Cable connecting the Controller
> > to the Drive, or new Cartridges are not so expensive as to be
> > non-starters, but I'm retired with limited income, and a new LTO
> > drive would be a real stretch.
> >
> > Here are three minutes of error notes from my last attempt in
> > kern.log/syslog:
> >
> > Nov 13 08:02:29 BigMutt kernel: [34669.493781] st 0:0:0:0:
> > device_block, handle(0x0009)
> > Nov 13 08:02:29 BigMutt kernel: [34669.493879] st 0:0:0:0: [st0]
> > Error e0000 (driver bt 0x0, host bt 0xe).
> > Nov 13 08:02:31 BigMutt kernel: [34671.743620] st 0:0:0:0:
> > device_unblock and setting to running, handle(0x0009)
> > Nov 13 08:02:31 BigMutt kernel: [34671.743714] st 0:0:0:0: [st0]
> > Error 10000 (driver bt 0x0, host bt 0x1).
> > Nov 13 08:02:31 BigMutt kernel: [34671.744077] st 0:0:0:0: [st0]
> > Error 10000 (driver bt 0x0, host bt 0x1).
> > Nov 13 08:02:31 BigMutt kernel: [34671.745089] mpt2sas_cm0: removing
> > handle(0x0009), sas_addr(0x500110a001622ed0)
> > Nov 13 08:02:31 BigMutt kernel: [34671.745091] mpt2sas_cm0:
> > enclosure logical id(0x500605b00341cef0), slot(0)
> > Nov 13 08:02:36 BigMutt kernel: [34676.006914] scsi 0:0:1:0:
> > Sequential-Access HP???????????? Ultrium 5-SCSI???? Z6ED PQ: 0 ANSI:
> > 6 Nov 13 08:02:36 BigMutt kernel: [34676.006922] scsi 0:0:1:0: SSP:
> > handle(0x0009), sas_addr(0x500110a001622ed0), phy(3),
> > device_name(0x500110a001622ed2)
> > Nov 13 08:02:36 BigMutt kernel: [34676.006924] scsi 0:0:1:0:
> > enclosure logical id (0x500605b00341cef0), slot(0)
> > Nov 13 08:02:36 BigMutt kernel: [34676.008694] scsi 0:0:1:0: TLR
> > Enabled Nov 13 08:02:36 BigMutt kernel: [34676.011053] st 0:0:1:0:
> > Attached scsi tape st0
> > Nov 13 08:02:36 BigMutt kernel: [34676.011056] st 0:0:1:0: st0: try
> > direct i/o: yes (alignment 4 B)
> > Nov 13 08:02:36 BigMutt kernel: [34676.011143] st 0:0:1:0: Attached
> > scsi generic sg2 type 1
> > Nov 13 08:05:24 BigMutt kernel: [34844.612941] st 0:0:1:0: [st0]
> > Block limits 1 - 16777215 bytes.
> >
> > So, is the culprit the LTO-5 drive? Cartridge? possibly the I/O
> > signal cable? the SAS Controller? What do I need to do to determine
> > the true cause of the errors with /dev/st0?
> >
> > LTO-5 SAS Tape on LSI SAS9211 controller
>
> This log suggests that the controller lost contact with the
> tape drive, reset it and at 8:02:36 re-recognized it.
>
> I would look at a cable (cheap!), then at whether you have
> sufficient power to keep the tape drive happy, before sending
> the tape drive to a repair specialist.
>
> -dsr-

If its the drive, and given the OP's stated money consraints, (I got 
tired of my tape drive spending the holidays in Oklahoma City) and as an 
amanda user of about 2 decades, I found it easy to convert amanda to 
use "vtapes" on a big hard drive.  Besides the advantage of random 
access when doing a recovery so its 100x faster, the big hard drive has 
the added advantage of the dependability of a hard drive.  Yes, in 15 
years I have replaced that drive, but not because it failed, but because 
my requirements out-grew it. The one I took out has 100,000+ spinning 
hours on it and I'm considering installing Buster on it. 

My smartest backup move ever was starting to use amanda in 1998, next 
smartest was switching it to use vtapes in about 2004. Biggest 
disadvantage to vtapes is the time depth of the backups. I am backing up 
5 machines nightly to a 2TB drive and can recover any of those to any 
date up to around 55 days ago. Drive is about 82% full. The data is not 
hidden in sequential access files, but is in fact in 60 directories, as 
tar files readily accessed by normal disk tools. I can with nothing 
except a bare bones install containing tar and gzip, restore to last 
nights backup before midnight my time on a new drive. All the OP needs 
is the price of the drive, likely much less than getting an LTO-5 
repaired. And of course a slot in his drive cage to carry it.  The 
choice was an easy one for me to make.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>


Reply to: