regressions.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* Re: Regression that causes data csum mismatch
       [not found] <da414ecc-f329-48ec-94d2-67c94755effb@gmx.com>
@ 2023-06-13 13:21 ` Linux regression tracking #adding (Thorsten Leemhuis)
       [not found] ` <20230613160247.GK13486@twin.jikos.cz>
  1 sibling, 0 replies; 2+ messages in thread
From: Linux regression tracking #adding (Thorsten Leemhuis) @ 2023-06-13 13:21 UTC (permalink / raw)
  To: Qu Wenruo, linux-btrfs; +Cc: Linux kernel regressions list

[CCing the regression list, as it should be in the loop for regressions:
https://docs.kernel.org/admin-guide/reporting-regressions.html]

[TLDR: I'm adding this report to the list of tracked Linux kernel
regressions; the text you find below is based on a few templates
paragraphs you might have encountered already in similar form.
See link in footer if these mails annoy you.]

On 13.06.23 08:26, Qu Wenruo wrote:
> 
> Recently I am testing scrub preparing for the incoming logical scrub.
> 
> But I noticed some rare and random test cases failure from scrub and
> replace groups.
> 
> E.g. btrfs/072 has a chance of failure around 1/30.
> 
> Initially I thought it's my scrub patches screwing things up, but with
> more digging, it turns out that it's real data corruption.
> 
> 
> After scrubbing found errors, btrfs check --check-data-csum also reports
> csum mismatch.
> 
> Furthermore this is profile independent, I have see all profiles hitting
> such data corruption.
> 
> Currently trying to bisect, but 6.4-rc4 already shows the bug.
> 
> And I can reproduce the problem on both x86_64 and aarch64 (both 4K page
> size)

Thanks for the report. To be sure the issue doesn't fall through the
cracks unnoticed, I'm adding it to regzbot, the Linux kernel regression
tracking bot:

#regzbot ^introduced v6.3..v6.4-rc6
#regzbot title btrfs: occasional data csum mismatch
#regzbot ignore-activity

This isn't a regression? This issue or a fix for it are already
discussed somewhere else? It was fixed already? You want to clarify when
the regression started to happen? Or point out I got the title or
something else totally wrong? Then just reply and tell me -- ideally
while also telling regzbot about it, as explained by the page listed in
the footer of this mail.

Developers: When fixing the issue, remember to add 'Link:' tags pointing
to the report (the parent of this mail). See page linked in footer for
details.

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
That page also explains what to do if mails like this annoy you.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: Regression that causes data csum mismatch
       [not found]     ` <20230615153219.GX13486@twin.jikos.cz>
@ 2023-06-15 18:00       ` Linux regression tracking (Thorsten Leemhuis)
  0 siblings, 0 replies; 2+ messages in thread
From: Linux regression tracking (Thorsten Leemhuis) @ 2023-06-15 18:00 UTC (permalink / raw)
  To: dsterba, Qu Wenruo; +Cc: linux-btrfs, Linux kernel regressions list

On 15.06.23 17:32, David Sterba wrote:
> On Wed, Jun 14, 2023 at 06:17:31AM +0800, Qu Wenruo wrote:
>> On 2023/6/14 00:02, David Sterba wrote:
>>> It would be good to share the updates to fstests with the tests. I've
>>> added the data csum check to _check_btrfs_filesystem.
>>>
>>>> Furthermore this is profile independent, I have see all profiles hitting
>>>> such data corruption.
>>>
>>> How does the corruption look like?
>>
>> Just some csum mismatch, which both scrub and btrfs check
>> --check-data-csum report.
>>
>> One of my concern here is the temperature of my environment, with AC
>> running it no longer reproduces...
>>
>> Hope it's really just a false alert.
> 
> No signs of problems so far, blaming it on overheating would fit the
> mysterious hard to reproduce bugs. We'll keep testing and see but this
> should not get a status of regression until we have something more
> concrete.

Don't worry, I was keeping an eye on it already after I saw Qu's msg and
would have removed it from the list of tracked issues before sending my
next report to Linus.

Anyway, with your additional confirmation, let me remove this from the
tracking right now:

#regzbot inconclusive: likely a overheating problem and not a regression
#regzbot ignore-activity

Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat)
--
Everything you wanna know about Linux kernel regression tracking:
https://linux-regtracking.leemhuis.info/about/#tldr
If I did something stupid, please tell me, as explained on that page.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-06-15 18:00 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <da414ecc-f329-48ec-94d2-67c94755effb@gmx.com>
2023-06-13 13:21 ` Regression that causes data csum mismatch Linux regression tracking #adding (Thorsten Leemhuis)
     [not found] ` <20230613160247.GK13486@twin.jikos.cz>
     [not found]   ` <0523f743-38e0-bc21-df4e-6a9d4e842ecf@gmx.com>
     [not found]     ` <20230615153219.GX13486@twin.jikos.cz>
2023-06-15 18:00       ` Linux regression tracking (Thorsten Leemhuis)

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).