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@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@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@ls1 ~]$ dd if=/dev/st1 of=junk2 bs=10240; cmp junk junk2 34+0 records in 34+0 records out [root@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@ls1 ~]$ df -k . Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda7 1004024 456760 496260 48% / [root@ls1 ~]$ dd if=/dev/st1 of=junk2 bs=10240 2576+1 records in 2576+1 records out [root@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@crc.dk Homepage: http://www.crc.dk
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list
-- fedora-list mailing list fedora-list@redhat.com To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list