All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Mason <chris.mason@oracle.com>
To: Stephan von Krawczynski <skraw@ithnet.com>
Cc: Lubos Kolouch <lubos.kolouch@gmail.com>, linux-btrfs@vger.kernel.org
Subject: Re: Question of stability
Date: Mon, 20 Sep 2010 08:27:45 -0400	[thread overview]
Message-ID: <20100920122745.GF27633@think> (raw)
In-Reply-To: <20100920142115.d05ac284.skraw@ithnet.com>

On Mon, Sep 20, 2010 at 02:21:15PM +0200, Stephan von Krawczynski wrote:
> On Mon, 20 Sep 2010 07:30:57 -0400
> Chris Mason <chris.mason@oracle.com> wrote:
> 
> > On Mon, Sep 20, 2010 at 11:00:08AM +0000, Lubos Kolouch wrote:
> > > No, not stable!
> > > 
> > > Again, after powerloss, I have *two* damaged btrfs filesystems.
> > 
> > Please tell me more about your system.  I do extensive power fail
> > testing here without problems, and corruptions after powerloss are very
> > often caused by the actual hardware.
> > 
> > So, what kind of drives do you have, do they have writeback caching on,
> > and what are you layering on top of the drive between btrfs and the
> > kernel?
> > 
> > -chris
> 
> Chris, the actual way how a fs was damaged must not be relevant. From a new fs
> design one should expect the tree can be mounted no matter what corruption took
> place up to the case where the fs is indeed empty after mounting because it
> was completely corrupted. If parts were corrupt then the fs should either be
> able to assist the user in correcting the damages _online_ or at least simply
> exclude the damaged fs parts from the actual mounted fs tree. The basic
> thought must be "show me what you have" and not "shit, how do I get access to
> the working but not mountable fs parts again?".
> Would you buy a car that refuses to drive if the ash tray is broken?

Definitely, this has always been one of our goals.  Step one is a better
btrfsck, which is in progress now.

Step two is being able to do more of this online.

-chris


      reply	other threads:[~2010-09-20 12:27 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-18 21:37 Question of stability Roy Sigurd Karlsbakk
2010-09-18 21:55 ` Hendrik Fabelje
2010-09-18 23:55   ` Roy Sigurd Karlsbakk
2010-09-19  0:43     ` C Anthony Risinger
2010-09-19  2:00       ` Roy Sigurd Karlsbakk
2010-09-19  4:50         ` C Anthony Risinger
2010-09-20 15:12       ` K. Richard Pixley
2010-09-20 15:27         ` C Anthony Risinger
2010-09-19  9:51     ` Hugo Mills
2010-09-20  1:18 ` Chris Samuel
2010-09-20 11:00   ` Lubos Kolouch
2010-09-20 11:30     ` Chris Mason
2010-09-20 12:10       ` Lubos Kolouch
2010-09-20 12:13         ` Chris Mason
2010-09-22 14:04           ` Lubos Kolouch
2010-09-22 22:50             ` Chris Mason
2010-09-20 12:21       ` Stephan von Krawczynski
2010-09-20 12:27         ` Chris Mason [this message]

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=20100920122745.GF27633@think \
    --to=chris.mason@oracle.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lubos.kolouch@gmail.com \
    --cc=skraw@ithnet.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.