From: Thorsten Kranzkowski <dl8bcu@dl8bcu.de>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Johannes Truschnigg <johannes@truschnigg.info>,
Willy Tarreau <w@1wt.eu>, Hillf Danton <dhillf@gmail.com>,
linux-kernel@vger.kernel.org,
Linux-Netdev <netdev@vger.kernel.org>
Subject: Re: PROBLEM: Silent data corruption when using sendfile()
Date: Sat, 14 Jul 2012 11:44:31 +0000 [thread overview]
Message-ID: <20120714114431.GA1190@ds20.borg.net> (raw)
In-Reply-To: <1342262004.3265.9279.camel@edumazet-glaptop>
On Sat, Jul 14, 2012 at 12:33:24PM +0200, Eric Dumazet wrote:
> On Sat, 2012-07-14 at 12:13 +0200, Johannes Truschnigg wrote:
> > On Sat, Jul 14, 2012 at 10:31:36AM +0200, Willy Tarreau wrote:
> > > > Please Johannes could you try latest kernel tree ?
> > >
> > > It would be useful, especially given the amount of changes you performed
> > > in this area in latest version, it could be very possible that this new
> > > bug got fixed as a side effect !
> >
> > I upgraded to 3.4.4 (identical config as the 3.4.0 build I've been running)
> > and what can I say - the problem really seems to have disappeared. I performed
> > about 3700 iterations of my previos tests over the night, and the data always
> > turned out to be OK, not a single byte turned out kaput!
> >
> > I wish I would have tested that earlier, and spared you the noise... well,
> > maybe someone who runs into a similar problem in the future will have this
> > discovery save her/him some time and headaches and make her/him just upgrade
> > kernels :)
> >
> > Thanks a lot for your polite and quick responses!
> >
>
> Nice to hear. Now we should make sure we have all needed fixes for prior
> stable kernels as well !
>
> Still trying to understand the issue, since I thought I only did
> optimizations, not bug fixes. So maybe real bug is still there but its
> probability of occurrence lowered enough to not hit your workload.
>
> Hmmm...
>
Not sure if this is related, but I had a similar data corruption problem:
Reading data from filesystem 'normally' (including through nfs) showed
corruption at random places, mostly 0xff tuning into 0xfe.
Reading with ODIRECT (I used 'dd iflag=direct') was OK.
I found my problem to be fixed by
fffaee365fded09f9ebf2db19066065fa54323c3 (upstrem)
which was backported as
b642cb6a143da812f188307c2661c0357776a9d0 (stable, v3.4.1-66-gb642cb6)
Bye,
Thorsten
--
| Thorsten Kranzkowski Internet: dl8bcu@dl8bcu.de |
| Mobile: ++49 170 1876134 Snail: Kiebitzstr. 14, 49324 Melle, Germany |
| Ampr: dl8bcu@db0lj.#rpl.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |
next prev parent reply other threads:[~2012-07-14 12:08 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-13 17:18 PROBLEM: Silent data corruption when using sendfile() Johannes Truschnigg
2012-07-14 8:04 ` Hillf Danton
2012-07-14 8:20 ` Eric Dumazet
2012-07-14 8:31 ` Willy Tarreau
2012-07-14 10:13 ` Johannes Truschnigg
2012-07-14 10:33 ` Eric Dumazet
2012-07-14 10:44 ` Willy Tarreau
2012-07-14 11:06 ` Eric Dumazet
2012-07-14 13:15 ` Willy Tarreau
2012-07-14 17:09 ` Johannes Truschnigg
2012-07-14 11:44 ` Thorsten Kranzkowski [this message]
2012-07-14 14:08 ` Hillf Danton
2012-07-14 14:19 ` Eric Dumazet
2012-07-14 14:56 ` Willy Tarreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120714114431.GA1190@ds20.borg.net \
--to=dl8bcu@dl8bcu.de \
--cc=dhillf@gmail.com \
--cc=eric.dumazet@gmail.com \
--cc=johannes@truschnigg.info \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.