[5224] in linux-scsi channel archive
Re: Linux 4mm SCSI DAT Drive Settings
daemon@ATHENA.MIT.EDU (Popov)
Sat Nov 28 03:58:10 1998
Date: Sat, 28 Nov 1998 00:22:39 -0800
From: Popov <popov@ix.netcom.com>
To: Martin Gallant <martyg@wired.ml.org>
CC: amanda-users@amanda.org, linux-scsi@vger.rutgers.edu
Hi,
Martin Gallant wrote:
> Hi! I've been running amanda on my home network for about six months
> now with a great deal of success. Saved my bacon a couple of times.
>
> I have a couple of hardware tuning questions I have not been able to
> find a definite answer to by scouring the 'net and my own testing.
> I therefore turn to your expertise.
>
> My system:
> - GNU/Linux i386 Debian v2.0.2, 2.0.3[3456] and 2.1.128 kernels
> - amanda-2.4.0, GNUTAR, software compression, 1Gig holding disk
> - WangDAT 3400DX (DDS-1/2, 4Gig native capacity) F/W v1.5a
> - Adaptec 2940 (narrow) SCSI controller
> - Tape drive hardware compression turned off
>
> Q1. By default, the system comes up with the driver configured in fixed
> block mode (512 bytes). Should I be setting the driver to variable
> block mode? (mt -f /dev/nst0 setblk 0) Will this impact
> interoperability with other drives if I ever need to move my tapes?
>
As far as I know, all DAT drives support both, variable and fixed block
modes.
> Q2. When I load a 60m/90m DDS-1 cartridge into the drive, "mt status"
> reports density code 0x13 (DDS-1). When I load a 120m DDS-2
> cartridge, the reported setting does NOT change. Is this normal? I
> expected the reported density to change to 0x24 (DDS-2). The reason
> I ask is I cannot get better than 2.5Gig native capacity on a DDS-2
> cartridge and I suspect the drive may be stuck in DDS-1 mode. This
> one has me stumped, I sure could use some advice on this issue.
If we exclude any obvious reasons, such as the drive is not DDS2 and the
tape really is DDS2, I really don't believe your drive is "stuck" in DDS1
mode -- you wouldn't get more than 2GB for one. The incorrect density
reporting is most likely a firmware bug -- it absolutely doesn't matter what
you
"set" the density to with mt. You can't force the drive to write illegal DDS
tapes
by shoving in a DDS2 tape and putting the drive in DDS1 density mode. If
the
firmware doesn't complain, it will certainly ignore your request. ... and I
just
don't believe that the WangDat firmware can be buggy enough to misdetect a
DDS2 tape as DDS1 and write it in DDS1 format. HP is the designated DDS
compatibility body and all DDS tape vendors send tapes with certain data
patterns
to HP to assure that each vendor can read the other vendors' tapes. If
WangDat
wrote DDS2 tapes with DDS1 track pitch, someone surely would have noticed
by now.
Your problem is most likely caused by high read-after-write error rates, in
which
case the drive ends up writting the same data over and over, thus reducing
the capacity. (You are not using a 120M DAT Audio tape, correct?)
You can get all of this info from the drive using the Log Sense command.
Try my scsi utility, stt, if you are interested:
http://www.netcom.com/~popov.
However, I tested the log sense dumps with a Sony tape drive, and ...
unfortunately the SCSI "standard" it butchered quite often, so do keep in
mind
that you might have to do some twicking to stt.
Try running a cleaning tape through the drive and try a different (new)
DDS2 tape.
> Q3. My nightly reports indicate transfer speeds on large (100's Megs,
> all fit on holding disk) level 0 dumps to be around 250kB/sec. The
> drive is rated at 350kB/Sec. Are there obvious things I can do to
> this thing to tune for a better transfer rate?
If the drive is experiencing high read-after-write error rates, the capacity
will be reduced and the performance will suffer. But, there are certainly
many other causes for decreased performance. How much data is your
software transferring per SCSI write command? Try increasing that
number if you can.
> Q4. Any other hints/tips for this setup?
>
> Many thanks for a most excellent backup/restore package. Cheers!
Pete
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.rutgers.edu
