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: [EMAIL PROTECTED] >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 [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
