From: Raviu <raviu@protonmail.com>
To: Nikolay Borisov <nborisov@suse.com>
Cc: "linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>
Subject: Re: fstrim segmentation fault and btrfs crash on vanilla 5.4.14
Date: Sun, 26 Jan 2020 17:10:30 +0000 [thread overview]
Message-ID: <hNqW0cNKaqya5Nvb99uUaI7KRF7zyl2urKDMfG6CkwEvLdLq6HlWnBLFrgtNCpleC2dfm8HLOHUdlQYPa1zi9zxfBaY1wwXli1mTAM-4qTQ=@protonmail.com> (raw)
In-Reply-To: <1a8462a7-c77b-ecc9-681f-3cecb6a51576@suse.com>
Here is the output of different btrfs filesystem subcommands:
`btrfs filesystem show /home`
Label: none uuid: 9c32ec4c-e918-4a79-92cf-c85faf3724e4
Total devices 2 FS bytes used 404.99GiB
devid 1 size 687.36GiB used 425.10GiB path /dev/mapper/cr_nvme0n1p4
devid 2 size 100.00GiB used 1.03GiB path /dev/mapper/cr_nvme0n1p1
`btrfs filesystem df /home`
Data, single: total=420.01GiB, used=403.48GiB
System, RAID1: total=32.00MiB, used=48.00KiB
System, DUP: total=32.00MiB, used=16.00KiB
Metadata, RAID1: total=1.00GiB, used=48.47MiB
Metadata, DUP: total=2.00GiB, used=1.46GiB
GlobalReserve, single: total=477.95MiB, used=0.00B
`btrfs filesystem usage /home`
Overall:
Device size: 787.36GiB
Device allocated: 426.13GiB
Device unallocated: 361.23GiB
Device missing: 0.00B
Used: 406.50GiB
Free (estimated): 377.75GiB (min: 197.14GiB)
Data ratio: 1.00
Metadata ratio: 2.00
Global reserve: 477.95MiB (used: 0.00B)
Data,single: Size:420.01GiB, Used:403.48GiB (96.07%)
/dev/mapper/cr_nvme0n1p4 420.01GiB
Metadata,RAID1: Size:1.00GiB, Used:48.47MiB (4.73%)
/dev/mapper/cr_nvme0n1p4 1.00GiB
/dev/mapper/cr_nvme0n1p1 1.00GiB
Metadata,DUP: Size:2.00GiB, Used:1.46GiB (73.12%)
/dev/mapper/cr_nvme0n1p4 4.00GiB
System,RAID1: Size:32.00MiB, Used:48.00KiB (0.15%)
/dev/mapper/cr_nvme0n1p4 32.00MiB
/dev/mapper/cr_nvme0n1p1 32.00MiB
System,DUP: Size:32.00MiB, Used:16.00KiB (0.05%)
/dev/mapper/cr_nvme0n1p4 64.00MiB
Unallocated:
/dev/mapper/cr_nvme0n1p4 262.26GiB
/dev/mapper/cr_nvme0n1p1 98.97GiB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, January 26, 2020 6:54 PM, Nikolay Borisov <nborisov@suse.com> wrote:
> On 26.01.20 г. 18:09 ч., Raviu wrote:
>
> > Here is dmesg output:
> > [ 237.525947] assertion failed: prev, in ../fs/btrfs/extent_io.c:1595
> > [ 237.525984] ------------[ cut here ]------------
> > [ 237.525985] kernel BUG at ../fs/btrfs/ctree.h:3117!
> > [ 237.525992] invalid opcode: 0000 [#1] SMP PTI
> > [ 237.525998] CPU: 4 PID: 4423 Comm: fstrim Tainted: G U OE 5.4.14-8-vanilla #1
> > [ 237.526001] Hardware name: ASUSTeK COMPUTER INC.
> > [ 237.526044] RIP: 0010:assfail.constprop.58+0x18/0x1a [btrfs]
> > [ 237.526048] Code: 0b 0f 1f 44 00 00 48 8b 3d 15 9e 07 00 e9 70 20 ce e2 89 f1 48 c7 c2 ae 27 77 c0 48 89 fe 48 c7 c7 20 87 77 c0 e8 56 c5 ba e2 <0f> 0b 0f 1f 44 00 00 e8 9c 1b bc e2 48 8b 3d 7d 9f 07 00 e8 40 20
> > [ 237.526053] RSP: 0018:ffffae2cc2befc20 EFLAGS: 00010282
> > [ 237.526056] RAX: 0000000000000037 RBX: 0000000000000021 RCX: 0000000000000000
> > [ 237.526059] RDX: 0000000000000000 RSI: ffff94221eb19a18 RDI: ffff94221eb19a18
> > [ 237.526062] RBP: ffff942216ce6e00 R08: 0000000000000403 R09: 0000000000000001
> > [ 237.526064] R10: ffffae2cc2befc38 R11: 0000000000000001 R12: ffffae2cc2befca0
> > [ 237.526067] R13: ffff942216ce6e24 R14: ffffae2cc2befc98 R15: 0000000000100000
> > [ 237.526071] FS: 00007fa1b8087fc0(0000) GS:ffff94221eb00000(0000) knlGS:0000000000000000
> > [ 237.526074] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 237.526076] CR2: 000032eed3b5a000 CR3: 00000007c33bc002 CR4: 00000000003606e0
> > [ 237.526079] Call Trace:
> > [ 237.526120] find_first_clear_extent_bit+0x13d/0x150 [btrfs]
>
> So you are hitting the ASSERT(prev) in find_first_clear_extent_bit. The
> good news is this is just an in-memory state and it's used to optimize
> fstrim so that only non-trimmed regions are being trimmed. This state is
> cleared on unmount so if you mount/remount then you shouldn't be hitting
> it.
>
> But then again, the ASSERT is there to catch an impossible case. To help
> me debug this could you provide the output of:
>
> btrfs fi show /home
>
> And then the output of btrfs inspect-internal dump-tree -t3 /dev/XXX
>
> where XXX should be the block device that contains the fs mounted on /home .
</nborisov@suse.com>
next prev parent reply other threads:[~2020-01-26 17:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-26 15:54 fstrim segmentation fault and btrfs crash on vanilla 5.4.14 Raviu
2020-01-26 16:09 ` Raviu
2020-01-26 16:54 ` Nikolay Borisov
2020-01-26 17:10 ` Raviu [this message]
[not found] ` <1DC5LVxi3doXrpiHkvBd4EwjgymRJuf8Znu4UCC-Ut0mOy9f-QYOyvQT3hf-QJX3Hk8hm_UhBGk_3rLcGYs_b6NdpNHDuJU-qog6PFxjEDE=@protonmail.com>
2020-01-27 7:53 ` Raviu
2020-01-27 8:03 ` Nikolay Borisov
2020-01-27 8:11 ` Raviu
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='hNqW0cNKaqya5Nvb99uUaI7KRF7zyl2urKDMfG6CkwEvLdLq6HlWnBLFrgtNCpleC2dfm8HLOHUdlQYPa1zi9zxfBaY1wwXli1mTAM-4qTQ=@protonmail.com' \
--to=raviu@protonmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@suse.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;
as well as URLs for NNTP newsgroup(s).