LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Hardware (https://www.linuxquestions.org/questions/linux-hardware-18/)
-   -   DDS4 Tape Drive woes with Debian (https://www.linuxquestions.org/questions/linux-hardware-18/dds4-tape-drive-woes-with-debian-616883/)

johnnyraga 01-28-2008 10:57 AM

DDS4 Tape Drive woes with Debian
 
Hello All,

I recently procured a DDS4 Tape Drive off ebay (Seagate STD2401LW, also known as an Archive Python 06408-XXX). Anyway, the long and short of it is that I am having a terrible time trying to get this device to function properly with Debian etch.

Issuing the command 'mt -f /dev/st0 status' with a tape inserted revealed that the drive code '0x26' was unrecognized by the default Debian driver, cpio-mt.

I then moved from cpio-mt to the mt-st package which seemed to fix that issue by recognizing the drive type and allowing me to compress the tape to take advantage of more than 20gb of data (DDS4's native storage capacity). Unfortunately, I've noticed that during nightly backups I'll run into two different types of errors.

The first type of error happens during verification of the data (which is a must in my situation). The second sometimes occurs while data is being written to the drive. The drive will act as though its gone through and written the full data set to disk (about 22gb) but it will only take 10 or so minutes to finish, which indicates that there's an error. The verification after this sort of error always fails.

Currently, the tape drive is the only device on the scsi chain, and its using a known good cable that has it's own active terminator at the end of the cable. The scsi card currently being used is your run of the mill Adaptec 2940uw.

I've tried swapping out both the scsi card and scsi cable for other known good parts and had the same bad results.

I was almost at the point of pitching this tape drive into the nearest garbage bin until I decided to try it under Windows (XP). To my chagrin (and utter disgust) it worked perfectly under Windows. I was able to copy about 21gb of data to a tape and verify the data using NTbackup.

Anyway, I need some suggestions because I'm stumped about what to do to get this thing working correctly under linux.

I should also mention that all my media is brand new and has been erased to verify proper formatting.

Thanks,

JR

johnnyraga 01-28-2008 02:04 PM

Additional thoughts
 
I've noticed that gnu cpio (the version that works with the mt-st tape driver)doesn't seem to function correctly with this device either. I wrote a script to back up a 10gb data directory that also verifies the data backed up after cpio is finished writing to the tape drive. Well, going through the error log of this script, I get a "/dev/tty not found" error.

Further research (google) indicates that this sort of error means cpio has run out of space on tape even though it should have more than enough room on the tape.

At this point, I'm pretty much ready to put this drive back up on ebay.

Any thoughts, ideas, recommendations?

JR

apolinsky 01-28-2008 04:01 PM

If the tape drive works properly using Windows, it does not sound like a hardware failure to me. I've used DDS-2 to DDS-4 tape drives in my Debian machine from Potato to Woody to Sarge and now Etch. My card is also an Adaptec 2940. Perhaps you could give additional information. I don't like seeing the 'issuing the command 'mt -f /dev/st0 status' with a tape inserted revealed that the drive code '0x26' was unrecognized by the default Debian driver'. I'm not sure in a one unit situation you need the terminator.

johnnyraga 02-01-2008 11:16 AM

mt, scsi, etc.
 
Thanks for the reply,

In my experience with scsi, a technology I work with on a daily basis, you need termination at each end of the scsi bus no matter what. It seriously cuts down on the various types of errors that can occur on a scsi bus.

The cpio-mt driver seeing a dds4 tape inserted as '0x26 unknown' is a known issue with that version of the driver. It's the main reason I switched to using mt-st because it recognizes dds4 drives correctly and it claims to support hardware compression as well.

My thought is that perhaps the drive is the issue. I'm not saying that its failing, we proved that it's in good working condition already under Windows. What I'm thinking is that it's in some way incompatible with the standard scsi tape drive commands in one or both of the mt drivers. Windows loads individualized drivers for every piece of hardware. It's one of the strengths/weaknesses of that platform. Maybe this is a situation where the generic linux drivers need some sort of tweaking to properly support this hardware.

I wouldn't know where to start tweaking things though.

Apolinsky, you said you've used DDS4 drives with Etch. What particular model were you using? What driver were you using too?

Thanks

JR

apolinsky 02-03-2008 10:08 AM

I am not sure of the tape drive number. As I recall it is a Seagate drive. As I recall, I strapped the drive with a jumper to force hardware compression. I use tar to send data to the drive. I assume you are trying to selectively back up files on the drive. If however, you are backing up the entire drive initially, and then changes, you might try 'dump' as your utility, assuming that your drive is formatted in ext2 or ext3. W. Curtis Preston who wrote the definitive book on backups recommends dump as the most reliable backup method. It is the main reason I have stayed with the ext3 file system. I have been told there are versions of dump available for XFS, or possibly JFS, but I haven't used them. I have moved the DDS-4 drive to a Centos 4 machine so I can't necessarily answer all questions intelligently. If you are still having troubles, I could move it back to Etch, and see what I can discover.


All times are GMT -5. The time now is 06:01 AM.