Linux Btrfs filesystem development
 help / color / mirror / Atom feed
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


  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