On Tue, Sep 13, 2005 at 09:56:38AM -0700, Marcus wrote: > I think I've been having trouble with used tapes so > I'm on new Fuji's now. Figured my data compression > woes would be gone now that I have true unformatted > tapes, but upon loading one, the drive's "DC" light > comes on. :P > > After that, set the drive to 40g/no compression and > wrote some data, then quit for bed. Turned the drive > on this morning and the "DC light is back on again! I > even checked for new firmware and tried shooting the > hex codes for No Compression to the drive, that didn't > seem to help.
on many dlt drives, you need to use "setdensity" instead. to list some densities, try: mt densi note that the densities are just hex codes, so there's nothing preventing you from setting an invalid code (i.e. the setdensity specified isn't checked for validity). for a specific example, a 160GB sdlt drive supports 110GB mode (it's the same media for both 110GB and 160GB drives). to tell the 160GB drive to write in 110GB mode, mt rewind mt setdensity 0x48 (setdensity only works while the tape is at BOT. otherwise, check out defdensity.) the more modern version of mt you have, the more density codes it will print with "mt densit". at the end of this email, i've included the output of "mt densit" from a redhat9 system. note that "mt status" will print out the current density code of the tape that's in the drive (which is not necessarily the density that will actually be written, assuming the tape is at BOT). (pardon the atrocious formatting, but i haven't slept for about 36 hours... > Rather then fight it, is there a problem with me > leaving data compression on? I wanted to avoid that > since I thought it would slow the drive down (my data > isn't very compressable). But the drive seems to > prefer (or provoke) running compressed. My high > priority is to prolong head life. > Thanks list! the older the drive, the slower the compression cpu chip inside it. on dat dds2 drives (archive/connor/seagate, etc.), compressing already compressed data will often slow the tape down. on newer hp dds3/dds4, it's harder to tell any difference. note that these drive models are reaching back from 6+ years (dds3) to well over 12 years (dds2), so modern drives will almost certainly have a fast enough cpu to deal with already-compressed data. > ***btw last time I asked, using mt's defcompression > came up. My version doesn't seem to have that command, > only datcompression which doesn't apply to dlt. i wish i knew why the tape interface/protocol standards fragmented so much. i miss the old 7-track reels, and even more the old dectape drive i played with on a pdp-1. here's the output from "mt densit" from an rh9 system: Some SCSI tape density codes: code explanation code explanation 0x00 default 0x21 QIC-20GB 0x01 NRZI (800 bpi) 0x22 QIC-2GB 0x02 PE (1600 bpi) 0x23 QIC-875 0x03 GCR (6250 bpi) 0x24 DDS-2 0x04 QIC-11 0x25 DDS-3 0x05 QIC-45/60 (GCR, 8000 bpi) 0x26 DDS-4 or QIC-4GB 0x06 PE (3200 bpi) 0x27 Exabyte Mammoth 0x07 IMFM (6400 bpi) 0x28 Exabyte Mammoth-2 0x08 GCR (8000 bpi) 0x29 QIC-3080MC 0x09 GCR (37871 bpi) 0x30 AIT-1 or MLR3 0x0a MFM (6667 bpi) 0x31 AIT-2 0x0b PE (1600 bpi) 0x33 SLR6 0x0c GCR (12960 bpi) 0x34 SLR100 0x0d GCR (25380 bpi) 0x40 DLT1 40 GB, or Ultrium 0x0f QIC-120 (GCR 10000 bpi) 0x41 DLT 40GB 0x10 QIC-150/250 (GCR 10000 bpi) 0x45 QIC-3095-MC (TR-4) 0x11 QIC-320/525 (GCR 16000 bpi) 0x47 TR-5 0x12 QIC-1350 (RLL 51667 bpi) 0x48 Quantum SDLT220 0x13 DDS (61000 bpi) 0x49 Quantum SDLT320 0x14 EXB-8200 (RLL 43245 bpi) 0x80 DLT 15GB uncomp. or Ecrix 0x15 EXB-8500 or QIC-1000 0x81 DLT 15GB compressed 0x16 MFM 10000 bpi 0x82 DLT 20GB uncompressed 0x17 MFM 42500 bpi 0x83 DLT 20GB compressed 0x18 TZ86 0x84 DLT 35GB uncompressed 0x19 DLT 10GB 0x85 DLT 35GB compressed 0x1a DLT 20GB 0x86 DLT1 40 GB uncompressed 0x1b DLT 35GB 0x87 DLT1 40 GB compressed 0x1c QIC-385M 0x88 DLT 40GB uncompressed 0x1d QIC-410M 0x89 DLT 40GB compressed 0x1e QIC-1000C 0x8c EXB-8505 compressed 0x1f QIC-2100C 0x90 EXB-8205 compressed 0x20 QIC-6GB -- Henry Yen Aegis Information Systems, Inc. Senior Systems Programmer Hicksville, New York ------------------------------------------------------- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
