All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: chainofflowers <chainofflowers@neuromante.net>,
	linux-btrfs@vger.kernel.org
Subject: Re: Access Beyond End of Device & Input/Output Errors
Date: Sat, 20 Feb 2021 19:42:33 +0800	[thread overview]
Message-ID: <33cd1bdb-814f-e0c3-e9e1-c876528f6a15@gmx.com> (raw)
In-Reply-To: <36f43213-14de-4dc0-074a-fa19babfed30@neuromante.net>



On 2021/2/20 下午7:26, chainofflowers wrote:
> Hi Qu!
>
> Is there any chance to find some hints of the issue in the log I attached?

Sorry for the late reply.

The weird part is, the access beyond boundary happens for read, no
wonder why previously added debug for discard doesn't work.

Currently I have no idea at all.

BTW, have you tried "btrfs check --check-data-csum"?
Regular btrfs check only check metadata but not data.

Considering how many the beyond boundary read there are, it looks like
some thing wrong related to data, thus "btrfs check --check-data-csum"
may help.

Another idea is to rule out memory corruption by running memtest, but I
doubt if it's the case.

Thanks,
Qu
>
> On 08.02.21 22:05, chainofflowers wrote:
>> Hi Qu!
>>
>> It happened again, and this time I've been able to dump the dmesg.
>> Also this time it happened on my home drive, please see the attached dump.
>>
>> What can I do to fix it?
>> btrfs scrub reports no error, neither does brfs check.
>> I have also remounted the partition with -oclear_cache,space_cache, I
>> hoped that could fix it...
>>
>> Thanks...
>>
>> (c)
>>

  reply	other threads:[~2021-02-20 11:44 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-17 23:38 Access Beyond End of Device & Input/Output Errors chainofflowers
2021-01-18  0:11 ` Qu Wenruo
2021-01-18 21:07   ` chainofflowers
2021-01-21 23:55     ` chainofflowers
2021-01-22  0:49       ` Qu Wenruo
2021-02-08 21:05         ` chainofflowers
2021-02-20 11:26           ` chainofflowers
2021-02-20 11:42             ` Qu Wenruo [this message]
2021-02-20 11:46           ` Forza
2021-02-20 12:07             ` chainofflowers
2021-02-20 12:13               ` Qu Wenruo
2021-04-23 23:36                 ` chainofflowers
2021-04-24  0:25                   ` Qu Wenruo
2021-04-24 14:13                     ` chainofflowers
2021-04-24 22:56                       ` Qu Wenruo
  -- strict thread matches above, loose matches on Subject: below --
2020-08-01  6:51 Justin Brown
2020-08-01  6:58 ` Qu Wenruo
2020-08-01  7:02   ` Qu Wenruo
     [not found]     ` <CAKZK7uzmg19NDjGPPAxXKu7LJ-7ZdHu2cad22csj_chr2qxMJg@mail.gmail.com>
2020-08-01  9:31       ` Qu Wenruo
2020-08-01 11:56         ` Justin Brown
2020-08-01 23:30           ` Qu Wenruo
2020-09-06  1:42             ` Justin Brown

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=33cd1bdb-814f-e0c3-e9e1-c876528f6a15@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=chainofflowers@neuromante.net \
    --cc=linux-btrfs@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 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.