From: Shaohua Li <shli@kernel.org>
To: Chien Lee <chienlee@qnap.com>
Cc: linux-raid@vger.kernel.org, NeilBrown <neilb@suse.com>,
owner-linux-raid@vger.kernel.org
Subject: Re: Enable the skip_copy feature will results in data integrity issue in raid5 degraded mode.
Date: Tue, 14 Feb 2017 16:36:23 -0800 [thread overview]
Message-ID: <20170215003623.swcqwm4pban6y66m@kernel.org> (raw)
In-Reply-To: <20170214194851.3txkw3nrcxczejyv@kernel.org>
On Tue, Feb 14, 2017 at 11:48:51AM -0800, Shaohua Li wrote:
> On Mon, Feb 13, 2017 at 05:07:45PM +0800, Chien Lee wrote:
> > Hello,
> >
> >
> > Recently we find a bug about skip_copy feature in raid5 degraded mode.
> > In the beginning, we enable the skip_copy feature to speed up system’s
> > write performance. But when the system has database read/write I/O
> > continually in raid5 degraded mode, the Mongo DB will detect the
> > checksum error and generate related debug log. The following is the
> > testing detail.
> >
> >
> > a. Enable skip_copy
> > --> Checksum error logs from Mongo DB
> >
> > 2017-02-06T11:54:56.537+0800 E STORAGE [conn7] WiredTiger (0)
> > [1486353296:537114][52:0x7f98396a4700],
> > file:collection-110-3235234017846331078.wt, WT_CURSOR.next: read
> > checksum error for 4096B block at offset 61440: calculated block
> > checksum of 1363526237 doesn't match expected checksum of 2969711960
> >
> >
> > b. Disable skip_copy
> > --> Mongo DB has no checksum error.
> >
> >
> > We've pretty sure that it must be a bug by our repeated database I/O
> > testing. When skip_copy feature is enabled, the raid5/raid6 always
> > causes the mongo DB checksum error in degraded mode less than one
> > hour. On the contrary, it will never cause this abnormal situation
> > when the skip_copy feature is disabled. Besides, because the skip_copy
> > feature only affects the write action instead of read action, I think
> > it should be the write action in degraded mode while skip_copy feature
> > is enabled cause this bug.
> >
> >
> > Please kindly provide us some help or idea about the root cause and solution.
>
> Thanks for the reporting, I'll look at it. In the meaning time, do you have a
> quick way which I can use to reproduce the issue?
Can't find anything suspicious after checking a while. Can you describe the
setup/test in detail? like if there is sync running, IO error?
prev parent reply other threads:[~2017-02-15 0:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-13 9:07 Enable the skip_copy feature will results in data integrity issue in raid5 degraded mode Chien Lee
2017-02-14 19:48 ` Shaohua Li
2017-02-15 0:36 ` Shaohua Li [this message]
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=20170215003623.swcqwm4pban6y66m@kernel.org \
--to=shli@kernel.org \
--cc=chienlee@qnap.com \
--cc=linux-raid@vger.kernel.org \
--cc=neilb@suse.com \
--cc=owner-linux-raid@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