On Sunday 20 July 2003 18:31, Freels, James D. wrote:
>OK.  I am learning from this. The number of 1k blocks on the first
>stored file on this tape is actually 384 and not 352.  I should have
>looked at the taper output and not the dumper output.   I issue the
>following multiple times:
>
>mt rewind
>mt -f=/dev/tape_norewind fsf 1
>dd if=/dev/tape_norewind of=./first_file bs=1k count=384
>
>the number of records read returned is
>
>64
>288
>384
>384
>64
>64
>384
>
>when it should be 384 every time !  Does this not smell of a
> hardware problem ?  Must be the scsi card ?

Yes it does on the face of it.

>If so, why don't I have other scsi errors on the hard drives ?
>
>Any ideas ?

The only additional one I keep stumbling over is that maybe this card
is so optimized for disk useage that its not quite kosher for a tape
drive.

If you are running the disks on this same card, a second ugly thought
comes to mind, and this is something that historicly seems to be
abused by tape drives more than disk drives, and that is the honoring
of the 'scsi disconnect', which is the situation where a command is
issued to a device on the scsi bus, and an immediate disconnect is
done, opening up the bus for use by other programs and such, leaving
it up to the device the command was issued to to notify the host that
the command has been done, and any data read (or written for that
matter) is now ready in the buffers to be read at the host and
controllers convienience.

Many tape drives ignore the disconnect message and lock the bus from
other uses by other devices until the command is completed.  I'm not
saying that it couldn't happen to a disk, but if its a true scsi-2 or
better, it should honor it.

You might investigate that aspect of it, and see if there are any
workarounds starting with the cards own bios configuration available
during the 'post' of a reboot.  If not, then that question might be
answered by putting a different card in for the tape drive by itself
so that it doesn't have to share a bus with disks that in all
probability do honor a disconnect correctly.

Other than those 2 possibilities, I'm fresh out of ideas.

>On Sun, 2003-07-20 at 05:00, Gregor Ibic wrote:
>> 
>> try to read the tape (or chunk - fsf) with dd
>> dd if=/dev/nst0 of=/XXXX bs=1024 count=NNNN
>> where NNN is greater than your backup job/disk entry
>> and see what happens
>>
>> i restored some valueable tape (MTF formated) reading this way and
>> putting the pieces together.
>>
>> regards,
>> gregor

--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz  512M
99.26% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attornies please note, additions to this message
by Gene Heskett are:
Copyright 2003 by Maurice Eugene Heskett, all rights reserved.

-- 
James D. Freels, Ph.D.
Oak Ridge National Laboratory
freelsjd AT ornl DOT gov