@jaime: "I am trying to replace an older DLT tape drive (which doesn't like to
eject tapes any more) with a new Quantum DLT-4 drive.  Its connected
by internal SCSI and seems to be set up right.  But after DAYS of
running a tar command, its still not done backing up 60GB.  The old
drive could backup 70-80GB in about 7 hours.
I changed my backup script to include a -v flag in the tar command,
and it now lists hundreds or possibly thousands of files.  But it
never even gets to /home before I killed the process (after 9 hours in
this case).
Any suggestions?
If it helps, the backup script and output from camcontrol follows.
However, this script is the same one that worked on the other drive.
A quick test with a Knoppix disk suggested that the backups ran faster
in Linux.  Not positive of this, but it might be true.
$ cat /etc/periodic/daily/910.backups
#!/bin/sh
#
echo
echo "Tape archives:"
dow=`/bin/date +%w`
if test "$dow" -gt 1;
then
	echo " Beginning backup."
	/usr/bin/uptime
	/usr/bin/tar -cvpX /usr/local/etc/backups/skiplist-relative.txt -f
/dev/sa0 -C / .
	/usr/bin/uptime
else
	echo " Today is a weekend.  Skipping backups."
fi
$ camcontrol devlist
<SEAGATE ST373207LW 0004>          at scbus0 target 0 lun 0 (pass0)
<SEAGATE ST373207LW 0004>          at scbus0 target 1 lun 0 (pass1)
<SEAGATE ST373207LW 0004>          at scbus0 target 2 lun 0 (pass2)
<LaCie BigDisk Extreme+ 3.AA>      at scbus1 target 0 lun 0 (da0,pass3)
<QUANTUM DLT-V4 0A00>              at scbus2 target 4 lun 0 (sa0,pass4)
Any help is greatly appreciated.
Thanks in advance,
Jaime"
    @dnelson: "<quote>
If nothing else, I suggest bumping up your blocksize.  The default for tar
(10k) is pretty small for modern tape drives.  Try -b 128 (for a 64k block
size).  Another optimization would be to put a buffering program in between
tar and your tape drive to decouple disk reads from tape writes.  misc/team,
misc/buffer, and misc/cstream in ports are good for this.
	Dan Nelson
	<email_address>"
    @jaime: "<quote>
Thanks.  Would this decrease the ability of other Unixes being able to
read the tape?  For example, using pax (which can read tar archives)
or GNU's tar?
Sadly, I forgot to mention something in my last message.  Sorry.
When reading from the tape using tar (bsdtar from FreeBSD 6.2  and,
yes, I'm preparing a cvsup as I write this :) ) the tape drive's Alarm
and Fault LEDs are lit up and then camcontrol devlist no longer shows
the tape drive.
After I wrote to the tape via a quick boot into Knoppix, I found that
FreeBSD's tar command could list the files on the tape.  So maybe that
is in the past now.  Maybe not.  I should have mentioned it earlier.
Sorry.
Any other thoughts before I try to OS update and the larger block size?
Jaime"
    @dkelly: "<quote>
[...]
You list -v as a tar option. Is tar sticking on a file?
Another question is whether or not tar could be getting caught in a hard
link or symbolic link infinite loop? Look for duplicates in the output.
uniq(1) should be of assistance. Perhaps uniq needs a sort(1) to
preprocess, I forget?
David Kelly N4HHE, <email_address>
========================================================================
Whom computers would destroy, they must first drive mad."
    @dnelson: "<quote>
It shouldn't.  At worst you may have to specify a matching blocksize
argument when reading.
According to
<url>
, there is no alarm LED on a DLT-V4 drive, just Ready, Fault, Clean, and
Media.  If the Fault light is lit solid, it says that's an "Internal
firmware error".  If Fault and Clean are blinking slowly, you may have a bad
tape or may need to put a cleaning tape in.
	Dan Nelson
	<email_address>"
    @jaime: "<quote>
I just added that to my script in order to see what was going on.  I
didn't use it a week ago.
I'm dumping straight to the tar drive.  Look at the tar command again
and you'll see /dev/sa0 in there.  :)
Not a bad thought.  However, I'm certain that there is no recursion
going on.  The delays are happening too early on for that.  Also, this
script works well if I target an external HD but never finishes on the
tape.
Thanks for the idea.  I hadn't considered it before.
Jaime"
    @dkelly: "<quote>
I once had problems with an SGI user writing tapes with megabyte block
size. Works on ancient SGI IRIX but nowhere else that I know of.
Worse, IRIX remembered the last block size used on a tape device, across
multiple users. Learned to always set block size when writing else no
telling how it would go.
David Kelly N4HHE, <email_address>
========================================================================
Whom computers would destroy, they must first drive mad."
    @jaime: "On Wed, Jan 28, 2009 at 4:51 PM, Wojciech Puchar
<quote>
I was thinking of that...  I shut down the server and checked the
usual suspects (terminator on the cable, SCSI IDs, etc.) but didn't
find anything out of place.  Also, the same command in Knoppix (Linux)
using /dev/st0 (the Linux equivalent of /dev/sa0) appeared to write to
the tape and then list the items on that tape.  I didn't see how long
it would take, though.  In retrospect, maybe I should have let that
run longer.  :(
How certain are you that its a termination problem?
Thanks,
Jaime"
    @dkelly: "<quote>
I'm tending to "certainly" agree.
There are other things to consider as well, such as narrow, wide, ultra,
and ultra-LVDT. Active termination and passive termination.
Is there termination at the SCSI card?
You said there was termination on the cable, but is there also on-board
termination on the drive?
No other drive on the bus has termination enabled?
One terminator on each end of the bus, no more, no less.
David Kelly N4HHE, <email_address>
========================================================================
Whom computers would destroy, they must first drive mad."
    @dkelly: "<quote>
Yes, usually a jumper is available. Also used to be one-shot fuses  
before the Raychem self-reseting PTC Polyswitch fuses.
David Kelly N4HHE, <email_address>
========================================================================
Whom computers would destroy, they must first drive mad."
{'source': 'USENET', 'other_information': '{"reply_count": 9, "forum_name": "lucky.freebsd.questions.20150205.mbox"}', 'file': 'data/output/usenet-lucky.freebsd.parquet'}