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 [EMAIL PROTECTED] 320M [EMAIL PROTECTED] 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.