Summary: ide-tape in 2.4.0-test8 seems to be unable to read the
last block of data in a stream, if the written data wasn't an
exact multiple of the tape unit's block size. 2.2.17 doesn't have
this problem.
Boot kernel 2.4.0-test8.
[root /tmp]# insmod ide-tape
[root /tmp]# dmesg | tail -2
ide-tape: hdd <-> ht0: Seagate STT8000A rev 5.51
ide-tape: hdd <-> ht0: 600KBps, 14*26kB buffer, 5850kB pipeline, 80ms tDSC, DMA
A Seagate TR-4 ATAPI "Hornet" drive. Apparently, the block size is 26k.
[root /tmp]# mt -f /dev/ht0 erase
[root /tmp]# dd if=/tmp/test.dat of=/dev/ht0 bs=1k
39+0 records in
39+0 records out
test.dat is 39k, so this seems ok.
[root /tmp]# dd if=/dev/ht0 of=/tmp/test.out bs=1k
26+0 records in
26+0 records out
ide-tape didn't read the last 13k. Very bad.
Reboot kernel 2.2.17. Same tape.
[root /tmp]# insmod ide-tape
[root /tmp]# dmesg | tail -1
ide-tape: hdd <-> ht0, 600KBps, 14*26kB buffer, 2600kB pipeline, 310ms tDSC, DMA
[root /tmp]# dd if=/dev/ht0 of=/tmp/test.out bs=1k
52+0 records in
52+0 records out
Got more than 39k -- padding, I guess.
[root /tmp]# dd if=/dev/ht0 of=/tmp/test.out bs=1k count=39
39+0 records in
39+0 records out
[root /tmp]# cmp /tmp/test.dat /tmp/test.out
Hmm. 2.4.0-test8 wrote the data ok, but cannot read it. 2.2.17 can.
[root /tmp]# mt -f /dev/ht0 erase
[root /tmp]# dd if=/tmp/test.dat of=/dev/ht0 bs=1k
39+0 records in
39+0 records out
[root /tmp]# dd if=/dev/ht0 of=/tmp/test.out bs=1k count=39
39+0 records in
39+0 records out
[root /tmp]# cmp /tmp/test.dat /tmp/test.out
2.2.17 writes and reads correctly. Good.
I haven't been bitten by this myself (for performance, I always set
the appropriate block size in my backup tools), but the behaviour
in 2.4 is clearly erroneous.
On August 8, Peter Baylies reported in lkml:
>From: pb@dev.localweb.com
>Subject: IDE Tape problem in 2.2.16 (bug?)
>Date: Tue, 8 Aug 2000 14:58:56 -0400 (EDT)
>
>I'm using a Seagate IDE tape drive (I understand it's basically a Travan
>tape drive) on kernel 2.2.16, and when I read from it, it doesn't read the
>last 18k from my backups; everything else seems to work.
>...
I almost ignored this report since I couldn't reproduce it in 2.2.17.
However, 2.4.0-test appears identical to what he described (down to
the kernel log messages), so perhaps he got his kernels mixed up.
/Mikael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Sep 15 2000 - 21:00:12 EST