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 13:58:39 +0800	[thread overview]
Message-ID: <a2f28c83-01c0-fce7-5332-2e9331f3c3df@gmx.com> (raw)
In-Reply-To: <CAOB=O_hdjpNtNtMMi93CFh3wO048SDVxMgBQd_pC0wx0C_49Ug@mail.gmail.com>


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



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

> 
> Dumb question, did I need to do that while booting a post 5.1 kernel?
> I ran these while not having the filesystem mounted, but against
> kernel 5.1.  I can easily repeat against 5.4.

Kernel version doesn't affect at all. All the detection and repair
should be able to be done by btrfs-progs.

But it would be better to use v5.4 to quick verify the fix is working.

Thanks,
Qu


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

  reply	other threads:[~2019-12-30  5:58 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 [this message]
2019-12-30  6:07             ` Patrick Erley
2019-12-30  6:09               ` Qu Wenruo
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=a2f28c83-01c0-fce7-5332-2e9331f3c3df@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).