From: Nikolay Borisov <nborisov@suse.com>
To: Raviu <raviu@protonmail.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: Mon, 27 Jan 2020 10:03:14 +0200 [thread overview]
Message-ID: <670bb0e5-aa42-2fd6-e15b-b1e11130c94b@suse.com> (raw)
In-Reply-To: <B5lXpRtqEz0NPuXGaaqp8p0AKY3ndP946GmHLVHkhHDPIntSm5HopHG8RCNWlyx8bw39N0NdjMh0PSMuCqZ6-yts7YUKhASbJ2oLx3z06aM=@protonmail.com>
On 27.01.20 г. 9:53 ч., Raviu wrote:
> Follow-up:
> It seems that I could solve my problem. Maybe this can also help you know the root cause and reproduce it some how.
> My buggy btrfs was initially on a single partition, I've freed another partition later and added as `btrfs device add` as the free partition was to the left of the original one so a resize was not possible.
> Originally I'd metadata as dup and data as single.
> Even after adding the new device it remained like that for few days, yesterday, I noticed it reported both dup and RAID1 of metadata which was weird. It did some sort of metadata balance on its own when it got a new partition, actually I didn't run such balance command before as both partition are on the same disk, so thought that raid-1 is useless.
> So I've taken a backup, then run `btrfs balance start -mconvert=raid1 /home/` .. So only raid1 is reported now on `btrfs filesystem df` and `btrfs filesystem usage`. I then run fstrim and it worked fine.
>
>
Yes, this is very hlepful. So if I got you correct you initially had
everything in a single disk. Then you added a second disk but you hadn't
run balance. And that's when it was crashing then you run balance and
now it's not crashing? If that's the case then I know what the problem
is and will send a fix.
next prev parent reply other threads:[~2020-01-27 8:03 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
[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 [this message]
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=670bb0e5-aa42-2fd6-e15b-b1e11130c94b@suse.com \
--to=nborisov@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=raviu@protonmail.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).