Yes, it is reproducible. In all my tests, I tarred 16 files of 16 MB each to
tape (I used a new one).
- test 1: 4 files with failed md5sum (no further investigation on type of
corruption)
- test 2: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were
corrupted, all starting at an offset of the form 32*x+1.
- test 3: 7 files with failed md5sum, 7 blocks of 32 consecutive bytes were
corrupted, all starting at an offset of the form 32*x+1.
The files seem to be corrupted during writing only, as reading always gives the
exact same (corrupted) data back.
Copying files from the disk on the MESH to a disk on the Sym53c875 (which also
has the tape drive) shows no corruption.
> you rip out the scsi_error patch in 2.4.3-preXX?
After reverting that patch, the problem got worse:
- test 4: 15 files with failed md5sum, a total of 40 blocks of 32 consecutive
bytes were corrupted, all starting at an offset of the form 32*x+1.
So it seems to be related to scsi_error.c.
If you have some suggestions, I'm willing to try them. I'd like to trust
whatever Amanda writes to my backup tapes :-)
Gr{oetje,eeting}s,
Geert
-- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.orgIn personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/