linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Patrick Erley <pat-lkml@erley.org>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: read time tree block corruption detected
Date: Mon, 30 Dec 2019 14:09:53 +0800	[thread overview]
Message-ID: <4c06d3a9-7f09-c97c-a6f3-c7f7419d16a7@gmx.com> (raw)
In-Reply-To: <CAOB=O_gBBjT9EVduHWHbF8iOsA8ua-ZGGh4s1x6Lia24LAZEMg@mail.gmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 3490 bytes --]



On 2019/12/30 下午2:07, Patrick Erley wrote:
> On Sun, Dec 29, 2019 at 9:58 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> On 2019/12/30 下午1:50, Patrick Erley wrote:
>>> On Sun, Dec 29, 2019 at 9:47 PM Patrick Erley <pat-lkml@erley.org> wrote:
>>>>
>>>> On Sun, Dec 29, 2019 at 9:43 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 2019/12/30 下午1:36, Patrick Erley wrote:
>>>>>> (ugh, just realized gmail does top replies.  Sorry... will try to
>>>>>> figure out how to make gsuite behave like a sane mail client before my
>>>>>> next reply):
>>>>>>
>>>>>> here's btrfs check /dev/nvme0n1p2 (sda3, which is a mirror of it, has
>>>>>> exactly the same output)
>>>>>>
>>>>>> [1/7] checking root items
>>>>>> [2/7] checking extents
>>>>>> [3/7] checking free space cache
>>>>>> [4/7] checking fs roots
>>>>>> [5/7] checking only csums items (without verifying data)
>>>>>> [6/7] checking root refs
>>>>>> [7/7] checking quota groups skipped (not enabled on this FS)
>>>>>> Opening filesystem to check...
>>>>>> Checking filesystem on /dev/nvme0n1p2
>>>>>> UUID: 815266d6-a8b9-4f63-a593-02fde178263f
>>>>>> found 89383137280 bytes used, no error found
>>>>>> total csum bytes: 85617340
>>>>>> total tree bytes: 1670774784
>>>>>> total fs tree bytes: 1451180032
>>>>>> total extent tree bytes: 107905024
>>>>>> btree space waste bytes: 413362851
>>>>>> file data blocks allocated: 90769887232
>>>>>>  referenced 88836960256
>>>>>
>>>>> It looks too good to be true, is the btrfs-progs v5.4? IIRC in v5.4 we
>>>>> should report inodes generation problems.
>>>>
>>>> Hurray Bottom Reply?
>>>>
>>>> /usr/src/initramfs/bin $ ./btrfs.static --version
>>>> btrfs-progs v5.4
>>
>> This is strange.
>>
>>
>> 6084adam|thinkpad|~$ btrfs check --mode=lowmem test.img
>> Opening filesystem to check...
>> Checking filesystem on test.img
>> UUID: c6c6ddd2-01c1-47fc-b699-cacfae9d4bfd
>> [1/7] checking root items
>> [2/7] checking extents
>> [3/7] checking free space cache
>> cache and super generation don't match, space cache will be invalidated
>> [4/7] checking fs roots
>> ERROR: invalid inode generation for ino 257, have 8858344568388091671
>> expect [0, 9)
>> ERROR: errors found in fs roots
>> found 131072 bytes used, error(s) found
>> total csum bytes: 0
>> total tree bytes: 131072
>> total fs tree bytes: 32768
>> total extent tree bytes: 16384
>> btree space waste bytes: 123409
>> file data blocks allocated: 0
>>  referenced 0
>> 6085adam|thinkpad|~$ btrfs --version
>> btrfs-progs v5.4
>>
>> As expected, v5.4 should detect such problem without problem.
>>
>> Would you please provide extra tree dump to help us to determine what
>> makes btrfs check unable to detect such problems?
>>
>> # btrfs ins dump-tree -b 303629811712 /dev/dm-1
> anvil ~ # btrfs ins dump-tree -b 303629811712 /dev/nvme0n1p2
> btrfs-progs v5.4
> Invalid mapping for 303629811712-303629815808, got 476092633088-477166374912
> Couldn't map the block 303629811712
> Couldn't map the block 303629811712
> bad tree block 303629811712, bytenr mismatch, want=303629811712, have=0
> ERROR: failed to read tree block 303629811712
> 
The bytenr is different from your initial report.

Anyway, you can try mount with v5.4, and use the bytenr from the dmesg.

Then please provide both dmeg (including the "corrupted leaf" line), and
the `btrfs ins dump-tree -b` output.

Thanks,
Qu


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 520 bytes --]

  reply	other threads:[~2019-12-30  6:10 UTC|newest]

Thread overview: 75+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-29 20:43 read time tree block corruption detected Patrick Erley
2019-12-29 22:07 ` Chris Murphy
2019-12-29 22:27   ` Patrick Erley
2019-12-29 22:32     ` Chris Murphy
2019-12-29 22:36       ` Patrick Erley
2019-12-29 23:11         ` Chris Murphy
2019-12-29 23:19           ` Patrick Erley
2019-12-29 23:24             ` Chris Murphy
2019-12-29 23:26               ` Patrick Erley
2019-12-30  0:46 ` Qu Wenruo
2019-12-30  5:36   ` Patrick Erley
2019-12-30  5:43     ` Qu Wenruo
2019-12-30  5:47       ` Patrick Erley
2019-12-30  5:50         ` Patrick Erley
2019-12-30  5:58           ` Qu Wenruo
2019-12-30  6:07             ` Patrick Erley
2019-12-30  6:09               ` Qu Wenruo [this message]
2019-12-30  8:14                 ` Patrick Erley
2019-12-30  8:54                   ` Qu Wenruo
2019-12-30  9:01                     ` Patrick Erley
2019-12-30  9:09                       ` Qu Wenruo
2019-12-30  9:21                         ` Patrick Erley
2019-12-30  9:27                           ` Qu Wenruo
2019-12-30 10:06                             ` Patrick Erley
2020-01-16 13:40 Peter Luladjiev
2020-01-16 16:12 ` Nikolay Borisov
     [not found]   ` <CA+ZCqs5=N5Hdf3NxZAmPCnA8wbcJPrcH8zM-fRbt-w8tL+TjUQ@mail.gmail.com>
2020-01-17  7:34     ` Nikolay Borisov
2020-01-17  7:51       ` Peter Luladjiev
2020-01-17  7:54         ` Peter Luladjiev
2020-01-17  7:59           ` Qu Wenruo
2020-01-17  8:14           ` Nikolay Borisov
2020-01-17  8:22             ` Peter Luladjiev
2020-01-17  9:10               ` Nikolay Borisov
2020-01-17 12:04                 ` Peter Luladjiev
2020-02-12 21:58 Samir Benmendil
2020-02-13  0:26 ` Qu Wenruo
2020-02-13 13:04   ` Samir Benmendil
2020-02-13 14:01   ` Qu Wenruo
2020-02-15 15:34     ` Samir Benmendil
     [not found] <CAJheHN0FUe-ijMco1ZOc6iKF2zbPocOw+iiVNeTT1r-JuXOJww@mail.gmail.com>
2020-05-06 21:54 ` Fwd: Read " Tyler Richmond
2020-05-06 23:55   ` Chris Murphy
2020-05-07  0:51     ` Tyler Richmond
2020-05-07  1:06       ` Chris Murphy
2021-04-16 19:35 read " Gervais, Francois
2021-04-17  1:01 ` Qu Wenruo
2021-04-19 13:20   ` Gervais, Francois
2021-04-19 13:33     ` Qu Wenruo
2021-04-19 14:56       ` Gervais, Francois
2021-04-20  1:34         ` Qu Wenruo
2021-04-20 14:19           ` Gervais, Francois
2021-04-20 23:47             ` Qu Wenruo
2021-04-21 14:17               ` Gervais, Francois
2021-04-21 23:01                 ` Qu Wenruo
2021-04-22 14:26                   ` Gervais, Francois
2021-05-26 23:03                     ` Gervais, Francois
2021-05-26 23:25                       ` Qu Wenruo
2021-07-17  1:45 Read " pepperpoint
2021-07-17  7:05 ` Qu Wenruo
     [not found] ` <162650555086.7.16811903270475408953.10183708@simplelogin.co>
2021-07-17  7:51   ` pepperpoint
     [not found]   ` <162650826457.7.1050455337652772013.10184548@mb.ardentcoding.com>
2021-07-17  8:14     ` Qu Wenruo
     [not found]     ` <162650966150.7.11743767259405124657.10185986@simplelogin.co>
2021-07-17  8:57       ` pepperpoint
2021-07-17 10:12         ` Qu Wenruo
     [not found]         ` <162651674065.6.7912816287233908759.10188327@simplelogin.co>
2021-07-17 10:34           ` pepperpoint
     [not found]           ` <162651809235.7.7061042874033963922.10188873@mb.ardentcoding.com>
2021-07-17 10:48             ` Qu Wenruo
     [not found]             ` <162651892663.6.17938009695497100557.10189169@simplelogin.co>
2021-07-17 12:51               ` pepperpoint
     [not found]               ` <CQeY09U34m7SrT6nTAlkSQrbLJtmyKF1tDfuGDtKUkwJqujMI_nZU4MpGiU4F_Q1U3Lk1aWD1mFCT5SlsOsOcILWECflIw7EhVQTQpy_1Ts=@email.ardentcoding.com>
2021-07-18  5:26                 ` pepperpoint
2021-07-18  7:15                   ` Qu Wenruo
     [not found]                     ` <162659327011.8.12718249358254503695.10218325@simplelogin.co>
2021-07-18  8:46                       ` pepperpoint
     [not found]                       ` <162659797656.6.14385932343235367381.10220447@mb.ardentcoding.com>
2021-07-18  9:32                         ` Qu Wenruo
     [not found]                         ` <162660074747.7.3300740266059717894.10221270@simplelogin.co>
2021-07-18 10:34                           ` pepperpoint
     [not found]                           ` <162660447733.8.9782212603273165785.10222524@mb.ardentcoding.com>
2021-07-18 11:13                             ` Qu Wenruo
     [not found]                             ` <162660684635.8.12423097770824212671.10223516@simplelogin.co>
2021-07-18 12:16                               ` pepperpoint
2021-11-22  5:26 read " x8062
2021-11-22  7:24 ` Nikolay Borisov
2021-11-22 10:07   ` x8062
2021-11-22 10:36     ` Nikolay Borisov
2021-11-23  2:42       ` x8062
2021-11-23  5:56         ` Nikolay Borisov

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=4c06d3a9-7f09-c97c-a6f3-c7f7419d16a7@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=pat-lkml@erley.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).