Re: Undo aic7xxx changes (now rc7+aic20030603)

[Willy Tarreau <willy@w.ods.org>]

Hi !

On Fri, Jun 20, 2003 at 06:13:53PM -0300, Marcelo Tosatti wrote:
> > Actually, without another copy of the data on a different system to
> > verify it with, you can't know that for sure. It could easily be getting
> > to the tape (the actual media) just fine, but then get corrupted during
> > the verify readback.
> 
> Right. Stephan, if you could use a bit of your time to isolate the problem
> I would be VERY grateful.

I remember Stephan once said that he used tar to verify the tape, and that for
one backup, he did several tests showing corruption on different files. Altough
that doesn't mean that the tape is written totally correctly, it at proves that
there's at least a read corruption.

I think that comparing multiple reads to find a pattern in corruption offsets
(if any) is the only thing he could do (not speaking about mixing read/writes
with good/bad kernels). Of course, storing several times 70GB on disk is not
easy, but at least a 16 bits checksum for each 1kB block would result on about
140 MB files, which will be "easier" to compare. It could be enough to check
for empty blocks, duplicated blocks or totally random ones.

Stephan, if you're willing to do the test but don't have such a tool, I may
write a quick dirty one tomorrow if that helps.

BTW, it could be interesting to note the read buffer's hardware address for
each test, in case it matters.

Cheers,
Willy