From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Daniel Holth <dholth@gmail.com>, <linux-btrfs@vger.kernel.org>
Subject: Re: bad areas cause btrfs segfault
Date: Mon, 29 Sep 2014 09:38:38 +0800 [thread overview]
Message-ID: <5428B81E.2090708@cn.fujitsu.com> (raw)
In-Reply-To: <CAG8k2+6MZHDH6Fb=RPW3=L1h63nk8SOWkZJ6JDR_aTZRWDP1wQ@mail.gmail.com>
Hi,
This bug seems to be one reported bug before:
http://article.gmane.org/gmane.comp.file-systems.btrfs/33270
And Chris has already updated the 3.13 stable branch to fix the bug.
If it is OK for you, updating kernel to 3.14 would be a solution.
(Since from 3.15, the new btrfs workqueue implementation caused some
bug, and will be fixed in 3.17,
3.15~3.16 is not recommended)
Thanks
Qu
-------- Original Message --------
Subject: bad areas cause btrfs segfault
From: Daniel Holth <dholth@gmail.com>
To: <linux-btrfs@vger.kernel.org>
Date: 2014年09月29日 09:11
> I've got a couple of directories that cause a btrfs segfault. First
> one happened at the end of July and I just renamed it to get it out of
> my way (can't delete it without crashing); the second one just
> happened and I'll be discarding the filesystem.
>
> This "crash when touched" behavior is frustrating because it makes it
> iffy to back up everything else. Usually about the second attempt to
> touch the bad directory requires a reboot.
>
> Instead, I would prefer that the filesystem not crash the whole system
> when it encounters a corrupted area.
>
> I've tried "btrfs scrub" and "btrfs check" but they don't find
> anything wrong. I guess the next step would be "btrfs restore", but I
> think I have a good enough backup made with a normal copy skipping the
> two corrupted directories.
>
> Here's my info.
>
> $ uname -a
> Linux cardamom 3.13.0-36-generic #63-Ubuntu SMP Wed Sep 3 21:30:07 UTC
> 2014 x86_64 x86_64 x86_64 GNU/Linux
>
> $ btrfs --version
> Btrfs v3.12
>
> $ btrfs fi show
> Btrfs v3.12
>
> $ btrfs fi df /home # Replace /home with the mount point of your
> btrfs-filesystem
> Data, single: total=110.01GiB, used=108.09GiB
> System, DUP: total=8.00MiB, used=20.00KiB
> System, single: total=4.00MiB, used=0.00
> Metadata, DUP: total=3.00GiB, used=2.31GiB
> Metadata, single: total=8.00MiB, used=0.00
next prev parent reply other threads:[~2014-09-29 1:38 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-29 1:11 bad areas cause btrfs segfault Daniel Holth
2014-09-29 1:38 ` Qu Wenruo [this message]
2014-09-29 1:47 ` Daniel Holth
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=5428B81E.2090708@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=dholth@gmail.com \
--cc=linux-btrfs@vger.kernel.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