Re: Undo aic7xxx changes (now rc7+aic20030603)

Bill Davidsen
2003-06-24T18:24:45Z

On Sat, 21 Jun 2003, Willy Tarreau wrote:

> 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.

Actually, to find problems like this, a change to cpio would be useful:

find /home | cpio -oB -Hcrc >/dev/st0

as an example. When reading back you will see errors from the CRC on each
file. I use cpio for this reason in some cases where knowing it's right
is critical.

--
bill davidsen <davidsen@tmr.com>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.