linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Heikki Tuuri" <Heikki.Tuuri@innodb.com>
To: <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.0-test2-mm3 and mysql
Date: Sun, 3 Aug 2003 12:10:01 +0300	[thread overview]
Message-ID: <009201c3599f$04ff05c0$322bde50@koticompaq> (raw)

Andrew,

I do not know about the specific corruption Shane is talking about, but I
could summarize what we have found out in the past 2 years. I have written
the InnoDB backend to MySQL, and have been hunting Linux corruption bugs for
2 years now.

- Corruption seems to happen on Red Hat kernels 2.4.18 under heavy file i/o
load on some computers.

- A user ran a very simple stress test of type SELECT 'abbaguu' with many
clients. On a 2-way Dell server he was able to get mysqld to crash
predictably in < 24 hours. Sometimes he also got corruption. But another,
cheaper computer worked ok. Both were running a Red Hat kernel 2.4.18. When
the user upgraded to a 'stock' kernel 2.4.20, the crashes and corruption
disappeared.

- Our 4-way Xeon SuSE-2.4.18 computer never corrupts databases, though I run
very heavy stress tests on it.

- Kernels 2.4.20 seem to be more reliable than 2.4.18. I have only one
corruption case from such a kernel.

- We know with certainty that corruption is sometimes caused by
OS/drivers/hardware and not by mysqld, because in some cases rebooting the
computer has magically fixed the corruption. Looks like Linux had corrupted
its own file cache, but the data on disk was ok. I reported this on the
Linux kernel mailing list 2 years ago, but got no definite feedback.

- In some cases InnoDB reports checksum errors in pages. In those cases it
is also very probable that the corruption was caused by OS/drivers/hardware,
and not by mysqld.

- I have not noticed any clear connection between corruption reports and the
used file system.

- I have personally tested on 4 Linux computers. On an old 2.2 kernel
computer I was able to get read errors in 30 seconds. The three 2.4 kernel
computers have worked ok.

My hypothesis is that there are bugs in drivers of Linux. That would explain
why some computers work ok. Or there are Linux kernel bugs which only
manifest on certain hardware under certain file i/o workload.

What to do? People who write drivers should run heavy, multithreaded file
i/o tests on their computer using some SQL database which calls fsync(). For
example, run the Perl '/sql-bench/innotest's all concurrently on MySQL. If
the problems are in drivers, that could help.

Best regards,

Heikki Tuuri
Innobase Oy

.................

List:     linux-kernel
Subject:  Re: 2.6.0-test2-mm3 and mysql
From:     Andrew Morton <akpm () osdl ! org>
Date:     2003-08-03 2:08:59
[Download message RAW]

Shane Shrybman <shrybman@sympatico.ca> wrote:
>
> The db corruption hit again on test2-mm2.

How do you know it is "db corruption"?

>
>  I am still backing out the 64 bit devt bit

why?



             reply	other threads:[~2003-08-03  9:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-03  9:10 Heikki Tuuri [this message]
2003-08-03  9:27 ` 2.6.0-test2-mm3 and mysql Andrew Morton
2003-08-03 10:43   ` Heikki Tuuri
2003-08-04 12:24     ` Denis Vlasenko
2003-08-04 18:29       ` Heikki Tuuri
2003-08-03 16:55 ` Matt Mackall
2003-08-03 17:11   ` Heikki Tuuri
2003-08-03 23:54     ` Matt Mackall
  -- strict thread matches above, loose matches on Subject: below --
2003-08-28 17:59 Heikki Tuuri
2003-08-28 19:01 ` Sergey S. Kostyliov
2003-08-28 19:10   ` Heikki Tuuri
2003-08-28 19:27     ` Sergey S. Kostyliov
2003-08-03 20:50 Heikki Tuuri
2003-08-03 16:59 Heikki Tuuri
2003-08-03 23:57 ` Matt Mackall
2003-08-03  0:38 Shane Shrybman
2003-08-03  1:04 ` Andrew Morton
2003-08-03  1:52   ` Con Kolivas
2003-08-03  1:59     ` Andrew Morton
2003-08-03  1:58   ` Shane Shrybman
2003-08-03  2:08     ` Andrew Morton
2003-08-03 15:01       ` Shane Shrybman
2003-08-03 19:25         ` Andrew Morton
2003-08-03 18:58   ` Sergey S. Kostyliov
2003-08-04  0:05     ` Matt Mackall
2003-08-27 15:52       ` Sergey S. Kostyliov

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='009201c3599f$04ff05c0$322bde50@koticompaq' \
    --to=heikki.tuuri@innodb.com \
    --cc=linux-kernel@vger.kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).