Linux Btrfs filesystem development
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: wojtasjd <wojtasjd@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: btrfs check --repair - hangs in infinite loop
Date: Tue, 28 May 2024 15:10:05 +0930	[thread overview]
Message-ID: <18218ba3-08a0-49c8-b83c-cfa9483cf746@gmx.com> (raw)
In-Reply-To: <e6dc5d0b-1f43-4aad-9189-3ba6e9031a5b@gmail.com>



在 2024/5/28 11:12, wojtasjd 写道:
> I have damaged btrfs file system (root partition for GNU/Linux LMDE 4
> with 4.19.x kernel which boots and mounts "/" read only, some files with
> 0 size, damaged timestamps and cannot be deleted because of I/O error).
>
> "btrfs check ..." (provided with LMDE 4) crashes with SegFault so I've
> booted to LMDE 6 live session and did some checks:
>
> root@mint:~# uname -a
> Linux mint 6.1.0-12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.52-1
> (2023-09-07) x86_64 GNU/Linux
>
> root@mint:~# btrfs --version
> btrfs-progs v6.2
>
> root@mint:~# mount /dev/sdb2 /mnt
>
> root@mint:~# btrfs fi show
> Label: none  uuid: 3a40ba85-56c2-4d26-a126-70839983f4a2
>      Total devices 1 FS bytes used 9.05GiB
>      devid    1 size 15.02GiB used 12.57GiB path /dev/sdb2
>
> root@mint:~# btrfs fi df /mnt
> Data, single: total=10.01GiB, used=8.62GiB
> System, DUP: total=32.00MiB, used=16.00KiB
> Metadata, DUP: total=1.25GiB, used=434.23MiB
> GlobalReserve, single: total=512.00MiB, used=0.00B
>
> root@mint:~# dmesg | tail -n 7
> [  404.266242] BTRFS info (device sdb2): using crc32c (crc32c-intel)
> checksum algorithm
> [  404.266264] BTRFS info (device sdb2): disk space caching is enabled
> [  404.558136] BTRFS critical (device sdb2): corrupt leaf: root=5
> block=29589504 slot=30 ino=1378764, invalid mode: has 00 expect valid
> S_IF* bit(s)
> [  404.558157] BTRFS error (device sdb2): read time tree block
> corruption detected on logical 29589504 mirror 1
> [  404.565225] BTRFS critical (device sdb2): corrupt leaf: root=5
> block=29589504 slot=30 ino=1378764, invalid mode: has 00 expect valid
> S_IF* bit(s)
> [  404.565244] BTRFS error (device sdb2): read time tree block
> corruption detected on logical 29589504 mirror 2
> [  404.565328] BTRFS error (device sdb2): could not do orphan cleanup -5
> root@mint:~#
>
> root@mint:~# btrfs inspect-internal logical-resolve 29589504 /mnt
> ERROR: logical ino ioctl: No such file or directory
>
> root@mint:~# umount /mnt
> root@mint:~# btrfs check --repair /dev/sdb2
> enabling repair mode
> WARNING:
>
>      Do not use --repair unless you are advised to do so by a developer
>      or an experienced user, and then only after having accepted that no
>      fsck can successfully repair all types of filesystem corruption. Eg.
>      some software or hardware bugs can fatally damage a volume.
>      The operation will start in 10 seconds.
>      Use Ctrl-C to stop it.
> 10 9 8 7 6 5 4 3 2 1
> Starting repair.
> Opening filesystem to check...
> Checking filesystem on /dev/sdb2
> UUID: 3a40ba85-56c2-4d26-a126-70839983f4a2
> [1/7] checking root items
> Fixed 0 roots.
> [2/7] checking extents
> corrupt leaf: root=5 block=29589504 slot=31, unexpected item end, have
> 4294979450 expect 12154

Please do not do the --repair unless you really know what you're doing.

At least you should run "btrfs check --readonly" and share it to the ML
before doing it.

> corrupt leaf: root=5 block=29589504 slot=31, unexpected item end, have
> 4294979450 expect 12154

This shows exactly what's going wrong, your hardware memory.

hex(4294979450) = 0x100002f7a
hex(12154)      = 0x000002f7a

One bit flipped inside the item size, causing the problem.

Btrfs-check can not handle such case well, as it doesn't expect such
insanely wrong values.

I won't risk --repair as such corruption can be very dangerous
especially you have already run repair once.

Thanks,
Qu

> corrupt leaf: root=5 block=29589504 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=29589504 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=32129024 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=29540352 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=32129024 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=29540352 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=32129024 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=29540352 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=32129024 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=29540352 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=32129024 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=29540352 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=32129024 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=29540352 slot=31, unexpected item end, have
> 4294979450 expect 12154
> corrupt leaf: root=5 block=32129024 slot=31, unexpected item end, have
> 4294979450 expect 12154
> ^C
> root@mint:~#
>
> btrfs in repair mode hangs in infinite loop and spits out info about
> corrupt leaf and two blocks like you can see above.
>
> I have image of disk.
>
> Can I repair this somehow?
>
>

      reply	other threads:[~2024-05-28  5:40 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-28  1:42 btrfs check --repair - hangs in infinite loop wojtasjd
2024-05-28  5:40 ` Qu Wenruo [this message]

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=18218ba3-08a0-49c8-b83c-cfa9483cf746@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=wojtasjd@gmail.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