From: Guoqing Jiang <guoqing.jiang@linux.dev>
To: Xiao Ni <xni@redhat.com>, "Tkaczyk, Mariusz" <mariusz.tkaczyk@intel.com>
Cc: Song Liu <song@kernel.org>,
linux-raid <linux-raid@vger.kernel.org>,
Heinz Mauelshagen <heinzm@redhat.com>,
Nigel Croxon <ncroxon@redhat.com>
Subject: Re: The read data is wrong from raid5 when recovery happens
Date: Mon, 29 May 2023 10:25:51 +0800 [thread overview]
Message-ID: <f4bff813-343f-6601-b2f8-c1c54fa1e5a1@linux.dev> (raw)
In-Reply-To: <CALTww297Q+FAFMVBQd-1dT7neYrMjC-UZnAw8Q3UeuEoOCy6Yg@mail.gmail.com>
On 5/26/23 15:23, Xiao Ni wrote:
>
>>>>> 6. mdadm /dev/md126 --add /dev/sdd
>>>>> 7. create 31 processes that writes and reads. It compares the content with
>>>>> md5sum. The test will go on until the recovery stops
>> Could you share the test code/script for step 7? Will try it from my side.
> The test scripts are written by people from intel.
> Hi, Mariusz. Can I share the test scripts here?
>
>>>>> 8. wait for about 10 minutes, we can see some processes report checksum is
>>>>> wrong. But if it re-read the data again, the checksum will be good.
>> So it is interim, I guess it appeared before recover was finished.
> Yes, it appears before recovery finishes. The test will finish once
> the recovery finishes.
>
>>>>> I tried to narrow this problem like this:
>>>>>
>>>>> - md_account_bio(mddev, &bi);
>>>>> + if (rw == WRITE)
>>>>> + md_account_bio(mddev, &bi);
>>>>> If it only do account for write requests, the problem can disappear.
>>>>>
>>>>> - if (rw == READ && mddev->degraded == 0 &&
>>>>> - mddev->reshape_position == MaxSector) {
>>>>> - bi = chunk_aligned_read(mddev, bi);
>>>>> - if (!bi)
>>>>> - return true;
>>>>> - }
>>>>> + //if (rw == READ && mddev->degraded == 0 &&
>>>>> + // mddev->reshape_position == MaxSector) {
>>>>> + // bi = chunk_aligned_read(mddev, bi);
>>>>> + // if (!bi)
>>>>> + // return true;
>>>>> + //}
>>>>>
>>>>> if (unlikely(bio_op(bi) == REQ_OP_DISCARD)) {
>>>>> make_discard_request(mddev, bi);
>>>>> @@ -6180,7 +6180,8 @@ static bool raid5_make_request(struct mddev *mddev,
>>>>> struct bio * bi)
>>>>> md_write_end(mddev);
>>>>> return true;
>>>>> }
>>>>> - md_account_bio(mddev, &bi);
>>>>> + if (rw == READ)
>>>>> + md_account_bio(mddev, &bi);
>>>>>
>>>>> I comment the chunk_aligned_read out and only account for read requests,
>>>>> this problem can be reproduced.
Only write bio and non aligned chunk read bio call md_account_bio, and
only account
write bio is fine per your test. It means the md5sum didn't match
because of non aligned
chunk read bio, so it is not abnormal that data in another chunk could
be changed with
the recovery is not finished, right?
BTW, I had run the test with bio accounting disabled by default, and
seems the result is
same.
> git tag --sort=taggerdate --contain 10764815f |head -1
v5.14-rc1
localhost:~/readdata #uname -r
5.15.0-rc4-59.24-default
localhost:~/readdata #cat /sys/block/md126/queue/iostats
0
And I can still see relevant log from the terminal which runs 01-test.sh
file /tmp/pythontest/data.out.nhoBR6 Test failed
(org_checksum|checksum_to_match) [582df4ccea6f5851462379fe4b17abf6
-|d41d8cd98f00b204e9800998ec
f8427e -]
file /tmp/pythontest/data.out.nhoBR6 calculate checksum again:
d41d8cd98f00b204e9800998ecf8427e -
file /tmp/pythontest/data.out.srGqF9 Test failed
(org_checksum|checksum_to_match) [7a85ec35b171e52ce41ebdd5da86f1d9
-|d41d8cd98f00b204e9800998ec
f8427e -]
file /tmp/pythontest/data.out.srGqF9 calculate checksum again:
d41d8cd98f00b204e9800998ecf8427e -
...
file /tmp/pythontest/data.out.q6m1kK Test failed
(org_checksum|checksum_to_match) [996f5bb5d2a2ddfd378a80a563ab4ad5
-|d41d8cd98f00b204e9800998ec
f8427e -]
file /tmp/pythontest/data.out.q6m1kK calculate checksum again:
d41d8cd98f00b204e9800998ecf8427e -
Rebuild ended, testing done!
stresstest end at : Sun May 28 22:23:53 EDT 2023
Sun May 28 22:23:53 EDT 2023
Thanks,
Guoqing
next prev parent reply other threads:[~2023-05-29 2:26 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CALTww28aV5CGXQAu46Rkc=fG1jK=ARzCT8VGoVyje8kQdqEXMg@mail.gmail.com>
2023-05-26 2:08 ` Fwd: The read data is wrong from raid5 when recovery happens Xiao Ni
2023-05-26 2:17 ` Yu Kuai
2023-05-26 2:40 ` Xiao Ni
2023-05-26 2:47 ` Yu Kuai
2023-05-26 3:02 ` Xiao Ni
2023-05-26 3:56 ` d tbsky
2023-05-26 6:20 ` Xiao Ni
2024-02-14 15:15 ` Fwd: " Mateusz Kusiak
2024-02-14 17:12 ` Song Liu
[not found] ` <CALTww29s1WupaVRSrEX1GbD=1Bt7b5cxseDnBLARkH1uHUhtCA@mail.gmail.com>
2024-02-15 10:41 ` Mateusz Kusiak
2023-05-26 3:09 ` Guoqing Jiang
2023-05-26 6:45 ` Xiao Ni
2023-05-26 7:12 ` Guoqing Jiang
2023-05-26 7:23 ` Xiao Ni
2023-05-26 9:13 ` Mariusz Tkaczyk
2023-05-26 21:13 ` Song Liu
2023-05-27 0:56 ` Xiao Ni
2023-07-11 0:39 ` Xiao Ni
2023-07-14 1:30 ` Yu Kuai
2023-05-29 2:25 ` Guoqing Jiang [this message]
2023-05-29 3:41 ` Xiao Ni
2023-05-29 8:33 ` Guoqing Jiang
2023-05-29 8:40 ` Xiao Ni
2023-05-30 1:36 ` Guoqing Jiang
2023-05-30 2:02 ` Yu Kuai
2023-05-30 2:11 ` Xiao Ni
2023-05-30 2:23 ` Guoqing Jiang
2023-05-30 2:30 ` Xiao Ni
2023-05-30 2:43 ` Guoqing Jiang
2023-06-14 8:27 ` Kusiak, Mateusz
2023-06-14 8:46 ` Xiao Ni
2023-05-29 13:51 ` Xiao Ni
2023-05-30 0:53 ` Guoqing Jiang
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=f4bff813-343f-6601-b2f8-c1c54fa1e5a1@linux.dev \
--to=guoqing.jiang@linux.dev \
--cc=heinzm@redhat.com \
--cc=linux-raid@vger.kernel.org \
--cc=mariusz.tkaczyk@intel.com \
--cc=ncroxon@redhat.com \
--cc=song@kernel.org \
--cc=xni@redhat.com \
/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