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.