SCSI tape problems

[T. Horsnell]

>>T. Horsnell wrote:
>>...
>>> The problem appears to be that the tapes drop records
>>> when being written, but that this can be fixed by increasing
>>> the blocksize.
>>...
>>
>>Are you sure that it is during the write operation?
>>
>>> [root at ls1 ~]$ dd if=tapetest500K of=/dev/st1 bs=10240 ; dd if=/dev/st1 of=junk bs=10240 ; cmp tapetest500K junk
>>> 48+1 records in
>>> 48+1 records out
>>> 36+1 records in
>>> 36+1 records out
>>> tapetest500K junk differ: byte 215041, line 854
>>
>>If you add another
>>
>>dd if=/dev/st1 of=junk2 bs=10240
>>
>>does that equal junk or is the error in another position?
>
>[root at ls1 ~]$ dd if=tapetest500K of=/dev/st1 bs=10240 ; dd if=/dev/st1 of=junk bs=10240 ; cmp tapetest500K junk
>48+1 records in
>48+1 records out
>34+0 records in
>34+0 records out
>tapetest500K junk differ: byte 153601, line 593
>[root at ls1 ~]$ dd if=/dev/st1 of=junk2 bs=10240; cmp junk junk2
>34+0 records in
>34+0 records out
>[root at ls1 ~]$ dd if=tapetest50M of=/dev/st1 bs=10240 ; dd if=/dev/st1 of=junk bs=10240 ; cmp tapetest50M junk
>4882+1 records in
>4882+1 records out
>2576+1 records in
>2576+1 records out
>tapetest50M junk differ: byte 153601, line 628
>[root at ls1 ~]$ df -k .
>Filesystem           1K-blocks      Used Available Use% Mounted on
>/dev/sda7              1004024    456760    496260  48% /
>[root at ls1 ~]$ dd if=/dev/st1 of=junk2 bs=10240
>2576+1 records in
>2576+1 records out
>[root at ls1 ~]$ diff junk junk2
>
>Furthermore, looking at the byte position at which cmp fails,
>its always on an exact record boundary. Also, I have a tape utility
>which can tell me the size of tape records. Using this I
>see that the last record (the fractional part if the filesize
>is not an integral number of tape-blocks) is always the correct size
>(I dont know whether it has the correct contents).

I'm lying here. All the ones I've checked so far had the correct
remnant-record-size, but I see from my test above, that one of
them doesnt ('34+0 records in' indicates no remnant).

>
>The problem still occurs if I make the filesize an integral number
>of tape-records.
>
>I'll put the tapelibrary back on my Alpha box and check what
>I get when I read tapes which were written on the Opteron.
>This should clinch the theory that its a write problem
>(or not, as the case may be)

When I put the lib back onto the Alpha, two test files (tapetest500K
and tapetest50M) written on the Opteron and read back on the Alpha,
matched the files as read back on the Opteron. This convinces me
that its (at least) a 'write' problem.


>
>>
>>The library has two drives, right? Is it a problem on
>>both drives?
>
>Yes. (See the end of my first post).
>
>Cheers,
>Terry.
>
>>
>>Mogens
>>
>>-- 
>>Mogens Kjaer, Carlsberg A/S, Computer Department
>>Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark
>>Phone: +45 33 27 53 25, Fax: +45 33 27 47 08
>>Email: mk at crc.dk Homepage: http://www.crc.dk
>>
>>-- 
>>fedora-list mailing list
>>fedora-list at redhat.com
>>To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
>>
>
>-- 
>fedora-list mailing list
>fedora-list at redhat.com
>To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
>