[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100520112945.61bf9705@mjolnir.ossman.eu>
Date: Thu, 20 May 2010 11:29:45 +0200
From: Pierre Ossman <pierre-list@...man.eu>
To: Tejun Heo <tj@...nel.org>
Cc: linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: Strange read data corruption on ext4/LVM/md
On Thu, 20 May 2010 10:57:29 +0200
Tejun Heo <tj@...nel.org> wrote:
> On 05/20/2010 09:14 AM, Pierre Ossman wrote:
> > Note that this is a live system, so there is some chance that something
> > wrote to than area, then restored it to the previous state. I'm not
> > sure how likely that is.
> >
> > If not, then it would seem that this is a problem in either the disks,
> > the controller or the controller driver. The components are WD
> > WD1002FAEX, sil3132 and sata_sil24 respectively.
>
> There is a report that sil3124/32 recognizes FIS corruption but keeps
> using the payload anyway thus leading to data corruption when the bus
> condition on pci-e side isn't ideal. Does moving the controller to
> different slot make difference?
>
The machine is rather crammed right now, with one controller in each of
the three available pci-e slots (5 disks). I am running continuous tests
on the disks right now though to see if the problems is on all disks or
just some. If just one slot is causing problems then we should see some
results there.
When you say FIS corruption, do you mean corruption in the sense of
randomly flipped bits? I don't know if you saw the first couple of
mails (before linux-ide was added), but the problem is data being moved
around, not just randomly changed.
Another note is that the problem seems to worsen under load. I'm
running the dd thing in the background, which seems to make read errors
more common on my test files on the filesystem level.
I also tried disabling NCQ without any noticeable change.
Rgds
--
-- Pierre Ossman
WARNING: This correspondence is being monitored by FRA, a
Swedish intelligence agency. Make sure your server uses
encryption for SMTP traffic and consider using PGP for
end-to-end encryption.
Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
Powered by blists - more mailing lists