All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hubert Kario <hka@qbs.com.pl>
To: Daniel Kozlowski <dan.kozlowski@gmail.com>
Cc: "Rodrigo E. De León Plicet" <rdeleonp@gmail.com>,
	linux-btrfs@vger.kernel.org
Subject: Re: Is there a more aggressive fixer than btrfsck?
Date: Tue, 29 Jun 2010 18:34:13 +0200	[thread overview]
Message-ID: <201006291834.13488.hka@qbs.com.pl> (raw)
In-Reply-To: <AANLkTilXNNQ8zxTGdjNBhI3kbMeTiT2tIN9PzjqHGWLz@mail.gmail.com>

On Tuesday 29 June 2010 12:37:45 Daniel Kozlowski wrote:
> On Mon, Jun 28, 2010 at 10:31 PM, Rodrigo E. De Le=F3n Plicet
>=20
> <rdeleonp@gmail.com> wrote:
> > On Mon, Jun 28, 2010 at 8:48 AM, Daniel Kozlowski
> >=20
> > <dan.kozlowski@gmail.com> wrote:
> >> Sean Bartell <wingedtachikoma <at> gmail.com> writes:
> >>> > Is there a more aggressive filesystem restorer than btrfsck?  I=
t
> >>> > simply gives up immediately with the following error:
> >>> >=20
> >>> > btrfsck: disk-io.c:739: open_ctree_fd: Assertion
> >>> > `!(!tree_root->node)' failed.
> >>>=20
> >>> btrfsck currently only checks whether a filesystem is consistent.=
 It
> >>> doesn't try to perform any recovery or error correction at all, s=
o it's
> >>> mostly useful to developers. Any error handling occurs while the
> >>> filesystem is mounted.
> >>=20
> >> Is there any plan to implement this functionality. It would seem t=
o me
> >> to be a pretty basic feature that is missing ?
> >=20
> > If Btrfs aims to be at least half of what ZFS is, then it will not
> > impose a need for fsck at all.
> >=20
> > Read "No, ZFS really doesn't need a fsck" at the following URL:
> >=20
> > http://www.c0t0d0s0.org/archives/6071-No,-ZFS-really-doesnt-need-a-=
fsck.h
> > tml
>=20
> Interesting idea. it would seem to me however that the functionality
> described in that article is more concerned with a bad transaction
> rather then something like a hardware failure where a block written
> more then 128 transactions ago is now corrupted and consiquently the
> entire partition is now unmountable( that is what I think i am lookin=
g
> at with BTRFS )

Still, the FS alone should be able to recover from such situations. Wit=
h=20
multiple superblocks the probability that the fs is unmountable is very=
 small
and if all superblocks are corrupted then you need a data recovery pror=
gram,=20
not fsck.

--=20
Hubert Kario
QBS - Quality Business Software
02-656 Warszawa, ul. Ksawer=F3w 30/85
tel. +48 (22) 646-61-51, 646-74-24
www.qbs.com.pl
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" =
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2010-06-29 16:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-06-02  2:29 Is there a more aggressive fixer than btrfsck? ulmo
2010-06-02 15:56 ` Sean Bartell
2010-06-28 13:48   ` Daniel Kozlowski
2010-06-29  2:31     ` Rodrigo E. De León Plicet
2010-06-29 10:37       ` Daniel Kozlowski
2010-06-29 16:34         ` Hubert Kario [this message]
2010-06-29 23:19           ` Anthony Roberts
2010-06-29 21:36         ` Freddie Cash
2010-06-29 22:22           ` Sean Bartell
2010-06-30  1:32             ` Chris Mason
     [not found]       ` <87eifov564.fsf@mid.deneb.enyo.de>
2010-07-01  3:38         ` Rodrigo E. De León Plicet
2010-07-01 10:09           ` Chris Mason

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=201006291834.13488.hka@qbs.com.pl \
    --to=hka@qbs.com.pl \
    --cc=dan.kozlowski@gmail.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=rdeleonp@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.