From: Marc MERLIN <marc@merlins.org>
To: ronnie sahlberg <ronniesahlberg@gmail.com>
Cc: Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Also seeing full deadlocks with 3.15.1
Date: Fri, 27 Jun 2014 15:33:40 -0700 [thread overview]
Message-ID: <20140627223340.GC28692@merlins.org> (raw)
In-Reply-To: <CAN05THQznt1=7yDTbJcwZqB149E3VueoTALmfyKJALQR9dPSAw@mail.gmail.com>
On Fri, Jun 27, 2014 at 02:50:10PM -0700, ronnie sahlberg wrote:
> > If I don't hear anything by the end of today, I'll just delete the
> > filesystem and start over.
>
> At some stage it would be nice to see not only fixes but also changes
> to fsck to make it able to repair these problems.
> Blow it away and create a new filesystem from scratch is sub-optimal.
I don't think you'll find disagreement from me or anyone here :)
But I'd go one step further. The filesystem is not corrupted as far as I
can tell, I'm happily copying data off it in ro,recovery mode (to
prevent background btrfs code from trying to do stuff and trip over
itself again).
The problem in my experience so far is that btrfs isn't stabilizing at
all. Some bugs are fixed, other things are changed, and new ones are
added.
I've not had a single version of btrfs in the last 4 kernels that didn't
deadlock and/or trip over itself (apparently from evolving or
balancing/filling filesystems into states where it can't handle them
properly anymore).
I really really wish we had a kernel release with only stabilizations
and where all recent deadlock and corruption problems (on newly created
filesystems) would be handled.
Right now, general state is bad enough that you can't tell if you hit a
new bug, or if it's an old bug that hasn't been fixed yet and developers
can't easily know if newer kernels have introduced regressions or not
since the general state of performance and stability isn't good across
all recent kernel versions.
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/ | PGP 1024R/763BE901
next prev parent reply other threads:[~2014-06-27 22:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-27 18:50 Also seeing full deadlocks with 3.15.1 Marc MERLIN
2014-06-27 20:40 ` Marc MERLIN
2014-06-27 21:50 ` ronnie sahlberg
2014-06-27 22:33 ` Marc MERLIN [this message]
2014-06-27 22:36 ` Josef Bacik
2014-06-27 23:59 ` Marc MERLIN
2014-06-28 0:14 ` Josef Bacik
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=20140627223340.GC28692@merlins.org \
--to=marc@merlins.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=ronniesahlberg@gmail.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 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.