All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew McNabb <amcnabb@mcnabbs.org>
To: linux-btrfs@vger.kernel.org
Subject: btrfs stability
Date: Fri, 25 Jan 2013 14:05:14 -0600	[thread overview]
Message-ID: <20130125200514.GD4217@mcnabbs.org> (raw)

I tried creating a multi-device btrfs filesystem for the first time (on
Fedora 18 with 3.7.2-204.fc18.x86_64), and I ran into some problems.  I
had heard that btrfs is now reasonably stable, and though I expected to
possibly see a problem here or there, I was a little surprised at just
how many problems I encountered in such a short period of time.  I now
have about a thousand error messages in my kernel logs related to
several different problems.  Is this roughly the expected level of
stability for btrfs with multiple devices, or am I just particularly
lucky? :)

Am I correct in assuming that I'll need to switch to md for a few months
and try btrfs again later, or are there known problems in the specific
kernel I'm running that I could avoid by trying a different version?

For the sake of being specific, I'll detail a few of the problems I've
hit:

These two may have been caused by a possibly faulty disk (I'm still
trying to determine whether it was faulty or whether the bug was purely
in btrfs):

https://bugzilla.redhat.com/show_bug.cgi?id=903794
https://bugzilla.redhat.com/show_bug.cgi?id=904143

This one was triggered when I tried to remove a possibly faulty disk:

https://bugzilla.redhat.com/show_bug.cgi?id=904197

With a freshly created filesystem, I got a kernel bug, associated with a
hang in most filesystem operations.  This occurred in the middle of
ordinary operation and without any sort of hardware-related errors in
the kernel logs.

https://bugzilla.redhat.com/show_bug.cgi?id=904223

I've noticed that a lot of the reports in the Fedora bugzilla and kernel
bugzilla don't seem to include much discussion; is there any specific
type of information that bug submitters should try to include to make
the reports more helpful?  Thanks.

--
Andrew McNabb
http://www.mcnabbs.org/andrew/
PGP Fingerprint: 8A17 B57C 6879 1863 DE55  8012 AB4D 6098 8826 6868

             reply	other threads:[~2013-01-25 20:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-25 20:05 Andrew McNabb [this message]
2013-01-25 20:37 ` btrfs stability Josef Bacik
2013-01-25 21:22   ` Andrew McNabb
2013-01-25 20:53 ` Josef Bacik
2013-01-25 21:39   ` Andrew McNabb
2013-01-26 20:27     ` Andrew McNabb
2013-01-28 14:17       ` Josef Bacik
2013-01-28 15:10       ` Josef Bacik
  -- strict thread matches above, loose matches on Subject: below --
2016-05-26 22:42 Diego Torres
2016-05-27  5:14 ` Roman Mamedov

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=20130125200514.GD4217@mcnabbs.org \
    --to=amcnabb@mcnabbs.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.