linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Pierre Abbat <phma@bezitopo.org>, linux-btrfs@vger.kernel.org
Subject: Re: Trying to mount hangs
Date: Thu, 21 May 2020 15:56:01 +0800	[thread overview]
Message-ID: <87436f2d-40d2-5fa1-cdee-4cc4f63e68c9@gmx.com> (raw)
In-Reply-To: <2549429.Qys7a5ZjRC@puma>


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



On 2020/5/21 上午9:34, Pierre Abbat wrote:
> I am not on the list, so please copy me.
> 
> Yesterday there was a double power blink. I rebooted my box and it appeared 
> normal, but a few hours later the web browser froze, then the panel froze. I 
> tried to kill the panel, but couldn't, and ended up rebooting. Then I couldn't 
> log in. I logged in as root on a text console and found out that /home wasn't 
> mounted. Trying to mount it hung the mount process.

That doesn't sound good. But according to your btrfs check result, your
memory doesn't look good.
There seems to be a memory bit flip.

A full memtest is highly recommended.

And since your hardware is not functioning reliable, everything can go
wrong.

> 
> I booted a thumb drive and tried "btrfs check /dev/mapper/puma-cougar" (the 
> device containing /home). It said it was busy. I ran btrfs-restore and 
> recovered source code files into /crypt (/mnt/crypt since I had booted the 
> thumb drive), which I then copied to another computer and pushed to GitHub. I 
> tried mounting puma-cougar with -o ro,recover, but mount still hung.
> 
> The next day (today, this morning) I bought an SSD, which I installed in the 
> afternoon. I ran btrfs-restore again, copying all files found to the SSD. I 
> changed /etc/fstab to point to the SSD, rebooted, and am back in business. 
> Running "btrfs check puma-cougar" now goes through, saying that there are some 
> errors.
> 
> I'd like to send you the filesystem so that you could figure out why mounting 
> hangs, but it's 138 GiB and I'd have to mail you a drive. Is there a way to 
> extract a skeleton that would still make mount hang, but that I could attach 
> to a bug report?
> 
> It was originally 128 GiB, but a week or two ago I ran out of space, moved the 
> point clouds to /crypt, and enlarged the LV. Maybe the combination of resizing 
> the filesystem and the power blink made it fail. Nothing went wrong with /
> crypt/.
> 
> What does "looping too much" mean?
> 
> phma@puma:~$ uname -a
> Linux puma 5.3.0-7625-generic #27~1576774560~19.10~f432cd8-Ubuntu SMP Thu Dec 
> 19 20:35:37 UTC  x86_64 x86_64 x86_64 GNU/Linux
> phma@puma:~$ btrfs --version
> btrfs-progs v5.2.1 
> phma@puma:~$ sudo su
> [sudo] password for phma: 
> root@puma:/home/phma# btrfs fi show
> Label: none  uuid: 155a20c7-2264-4923-b082-288a3c146384
>         Total devices 1 FS bytes used 67.60GiB
>         devid    1 size 158.00GiB used 70.02GiB path /dev/mapper/concolor-
> cougar
> 
> Label: none  uuid: 10c61748-efe7-4b9c-b1f7-041dc45d894b
>         Total devices 1 FS bytes used 53.36GiB
>         devid    1 size 127.98GiB used 56.02GiB path /dev/mapper/cougar-crypt
> 
> Label: none  uuid: 1f5a6f23-a7ef-46c6-92b1-84fc2f684931
>         Total devices 1 FS bytes used 92.58GiB
>         devid    1 size 158.00GiB used 131.00GiB path /dev/mapper/puma-cougar
> 
> root@puma:/home/phma# btrfs check /dev/mapper/puma-cougar 
> Opening filesystem to check...
> Checking filesystem on /dev/mapper/puma-cougar
> UUID: 1f5a6f23-a7ef-46c6-92b1-84fc2f684931
> [1/7] checking root items
> [2/7] checking extents
> incorrect local backref count on 4186230784 root 257 owner 99013 offset 
> 5033684992 found 1 wanted 2097153 back 0x5589817e5ef0

Here, the 2097153 is 0x200001, it's an obvious bitflip.

And since it's in extent tree, even write time tree checker can't detect it.

But that problem is not a big thing, btrfs check --repair can fix it.

Still, memtest first, only process to try repair after your memory is fixed.

Thanks,
Qu


> backpointer mismatch on [4186230784 188416]
> ERROR: errors found in extent allocation tree or chunk allocation
> [3/7] checking free space cache
> [4/7] checking fs roots
> root 257 inode 30648207 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648208 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648209 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648210 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648211 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648212 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648213 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648214 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648215 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648216 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648217 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648218 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648219 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> root 257 inode 30648220 errors 100, file extent discount
> Found file extent holes:
>         start: 0, len: 4096
> ERROR: errors found in fs roots
> found 99403300864 bytes used, error(s) found
> total csum bytes: 96230456
> total tree bytes: 737820672
> total fs tree bytes: 534069248
> total extent tree bytes: 75481088
> btree space waste bytes: 129276390
> file data blocks allocated: 10627425239040
>  referenced 68243042304
> 
> Pierre
> 


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

  reply	other threads:[~2020-05-21  7:56 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-21  1:34 Trying to mount hangs Pierre Abbat
2020-05-21  7:56 ` Qu Wenruo [this message]
2020-05-21 23:48   ` Pierre Abbat
2020-05-22  1:32     ` Qu Wenruo
2020-05-22  9:40       ` Pierre Abbat
2020-05-22 10:02         ` Qu Wenruo
2020-05-24  6:37           ` Pierre Abbat
2020-05-24  9:24             ` Qu Wenruo
2020-05-24 12:10               ` Pierre Abbat
2020-05-24 12:32                 ` Qu Wenruo
2020-05-27 10:41 ` Qu Wenruo

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=87436f2d-40d2-5fa1-cdee-4cc4f63e68c9@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=phma@bezitopo.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).