[nflug] tape drive problems (scsi)

[ptgoodman]

Hi Cyber Source,

These are external DAT ( or some variation ) drives? OK, you wrote that 
;-)! I agree it _seems_ like a setup problem, rather than a hardware 
problem, unless... It could be a hardware setup problem. Is the SCSI 
cabling properly terminated at all problem locations? Some 
auto-terminate. You may have to check inside the drive box to ensure 
that the DIP switches are set properly for your operating system ( of 
course, I don't know what that is )...this I know from painful 
experience on an SGI/UNIX system. You can check the manufacturer's web 
site for info on DIP switch settings ( yes, they can be very important 
)--note, for example, that an Emerald drive may have a HP DAT drive in 
the box, so you'd need to go to a HP web site for this information. My 
memory is telling me that my failing to properly set the DIP switches 
caused an error message very much like the one your are getting and that 
the backups sometimes "seemed" to be proceeding properly when they were 
not. I'm guessing that you have checked SCSI ID settings at all 
locations to avoid SCSI device conflicts.

Under SGI/UNIX there were a couple files that needed to be modified and 
the UNIX OS rebuilt to actually recognize the tape drive and its 
characteristics ( e.g. blocksize ). One such file required a fairly long 
entry that fully completely described the tape drive to the OS. Can't 
remember the files, but one had entries for _all_ devices on the system.

Question. You can do sequential backups on DDS drives? Not too long ago, 
this was not possible. mt would still perform the various functions. 
Still, I'm not sure that "mt erase" or "mt rewind" are required. Tar did 
it all.

It's been quite a while since I worked on this issue, so I can't be much 
more specific. If I could see it, feel it, touch it ( the problem that 
is ), I might be able to help more. There's probably more information on 
this packed away someplace in my brain.

good luck,
pete

Cyber Source wrote:

> Hello All,
>  I have been starting to use scsi tape drives at a couple locations 
> for backups and have encountered the same intermittent type of 
> troubles at both locations, which is why I think it's something in my 
> setups and not the hardware. Here is my problem, I'll stick to one 
> location as once I figure it out, will probably explain the other. I 
> have not been able to get reliable consistent backups going to these 
> tape drives, sometimes they work, more often they don't. I have an 
> external DDS-3 with the following info result from an mt status;
>
> [root at softbase ~]# mt status
> SCSI 2 tape drive:
> File number=0, block number=0, partition=0.
> Tape block size 512 bytes. Density code 0x25 (DDS-3).
> Soft error count since last status=0
> General status bits on (41010000):
> BOT ONLINE IM_REP_EN
>
> Now, I have a very rudimentary  script  as a cron like so ( I don't 
> need sequential backups, etc. )
>
> #!/bin/bash
> mt erase
> tar cvf /dev/st0 /Backup/Monday
> mt rewind
>
> Here is an error message from last nights (dmesg output)
>
> st0: Error with sense data: <6>st0: Current: sense key: Medium Error
>    Additional sense: Excessive write errors
> st0: Error with sense data: <6>st0: Current: sense key: Hardware Error
>    Additional sense: Internal target failure
> Info fld=0x14
> st0: Error with sense data: <6>st0: Current: sense key: Hardware Error
>    Additional sense: Internal target failure
> Info fld=0x1
> st0: Error on write filemark.
> st0: Error with sense data: <6>st0: Current: sense key: Hardware Error
>    Additional sense: Internal target failure
> st0: Error with sense data: <6>st0: Current: sense key: Hardware Error
>    Additional sense: Internal target failure
>
> NOTE: This is the first time I have seen anything calling Hardware 
> Error. Now if I remove the st module and put it back in, I get this 
> from dmesg;
>
> st: Unloaded.
> st: Version 20050830, fixed bufsize 32768, s/g segs 256
> st 3:0:0:0: Attached scsi tape st0<4>st0: try direct i/o: yes 
> (alignment 512 B), max page reachable by HBA 1048575
> st0: Block limits 1 - 16777215 bytes.
>
> So, my question would be, do I need to set a block size in my script 
> to make this more reliable? I have read the man page on mt (and st), 
> lots of options but no examples (so many scsi options). Anyway, so I 
> might save myself tons of trial and error, can anyone give me a clue? 
> Thanks, Peter
>
> _______________________________________________
> nflug mailing list
> nflug at nflug.org
> http://www.nflug.org/mailman/listinfo/nflug
>

_______________________________________________
nflug mailing list
nflug at nflug.org
http://www.nflug.org/mailman/listinfo/nflug