Messages in this thread | | | Date | Mon, 30 Jun 2003 14:08:04 +0200 | From | Stephan von Krawczynski <> | Subject | Re: Undo aic7xxx changes (now rc7+aic20030603) |
| |
On Mon, 30 Jun 2003 08:39:38 -0300 (BRT) Marcelo Tosatti <marcelo@conectiva.com.br> wrote:
> > > On Mon, 30 Jun 2003, Stephan von Krawczynski wrote: > > > Hello all, > > > > it looks like the problem gets worse currently. This is the second day I > > see 4 verification errors. This is with kernel 2.4.22-pre2 now. > > > As far as I understood, the tape is corrupting the data (or writting, or > when reading back). > > Is this correct?
Actually my guess is that the _data_ itself is not corrupt, neither the original set located on 3ware RAID nor the backup'ed set on aic-connected SDLT. The problem is - according to my personal opinion - flawed during the readback that occurs while verifying. I do not know if the data is already corrupted by the aic-driver (less probable currently) or some flaw inside the caching of the _original_ set. The situation is complex because of the multiple involved subsystems.
My experience is this:
If you reboot and make backup/verify cycle from 3ware to aic/tape everything seems fine.
If you reboot and push data over NFS to 3ware-disk, then do the backup/verify cycle (with this data) from 3ware to aic/tape the corruption is very likely.
If you do try another verify run of the data you see corruptions happen on _other_ files than the verify before. It is therefore unlikely that both data "ends" are part of the problem, because you would expect the same corruptions to show up - at least this is my hope.
Regards, Stephan
- 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/
| |