linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Martin Steigerwald <martin@lichtvoll.de>
To: John Center <jlcenter15@gmail.com>
Cc: Duncan <1i5t5.duncan@cox.net>, linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs scrub failing
Date: Sun, 03 Jan 2016 11:06:16 +0100	[thread overview]
Message-ID: <2304914.ebMOxPbdB3@merkaba> (raw)
In-Reply-To: <CAPgWCbRZOT-LvECuqgbaHSKWE8mYiO5R9kvk-8BeL-9Lb85fVA@mail.gmail.com>

Am Sonntag, 3. Januar 2016, 02:02:12 CET schrieb John Center:
> Hi Martin & Duncan,

Hi John,

> Since I had a backup of my data, I first ran "btrfs check -p" on the
> unmounted array.  It first found 3 parent transid errors:
> 
> root@ubuntu:~# btrfs check -p /dev/md126p2
> Checking filesystem on /dev/md126p2
> UUID: 9b5a6959-7df1-4455-a643-d369487d24aa
> parent transid verify failed on 97763328 wanted 33736296 found 181864
> ...
> Ignoring transid failure
> parent transid verify failed on 241287168 wanted 33554449 found 17
> ...
> Ignoring transid failure
> parent transid verify failed on 1016217600 wanted 33556071 found 1639
> ...
> Ignoring transid failure
> 
> Then a huge number of bad extent mismatches:
> 
> bad extent [29360128, 29376512), type mismatch with chunk
> bad extent [29376512, 29392896), type mismatch with chunk
> ...
> bad extent [1039947448320, 1039947464704), type mismatch with chunk
> bad extent [1039948005376, 1039948021760), type mismatch with chunk

Due to these I recommend you redo the BTRFS filesystem using your backup. See 
the other thread where Duncan explained the situation that this may be a sign 
of a filesystem corruption introduced by a faulty mkfs.btrfs version.

I had this yesterday with one of my BTRFS filesystems and these type mismatch 
things didn´t go away with btrfs check --repair from btrfs-tools 4.3.1.

Also

> Next:
> 
> Couldn't find free space inode 1
> checking free space cache [o]
> parent transid verify failed on 241287168 wanted 33554449 found 17
> Ignoring transid failure
> checkingunresolved ref dir 418890 index 0 namelen 15 name umq-onetouch.ko
> filetype 1 errors 6, no dir index, no inode ref
>     unresolved ref dir 418890 index 8 namelen 15 name ums-onetouch.ko
> filetype 1 errors 1, no dir item

the further errors and

[…]
> Once it finished, I tried a recovery mount, which went ok.  Since I already
> had a backup of my data, I tried to run btrfs repair:
> […]
> Then it got stuck on the same error as before.  It appears to be a loop:
> 
> parent transid verify failed on 1016217600 wanted 33556071 found 1639
> Ignoring transid failure
> parent transid verify failed on 1016217600 wanted 33556071 found 1639
> Ignoring transid failure
> ...
[…]
> It's been running this way for over an hour now, never moving on from the
> same errors & the same couple of files.  I'm going to let it run overnight,
> but I don't have a lot of confidence that it will ever exit this loop.  Any
> recommendations as what I should do next?

is a clear sign to me that it likely is more effective to just redo the 
filesystem from scratch than trying to repair it with the limited capabilities 
of current btrfs check command.

So when you have a good backup of your data and want to be confident of a 
sound structure of the filesytem, redo it from scratch with latest btrfs-tools 
4.3.1.

Thats at least my take on this.

Thanks,
-- 
Martin

  parent reply	other threads:[~2016-01-03 10:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-31 16:20 btrfs scrub failing John Center
2016-01-01  5:55 ` Duncan
2016-01-01 16:41   ` John Center
2016-01-01 17:05     ` Duncan
2016-01-01 18:31       ` John Center
2016-01-02  1:04       ` John Center
2016-01-02  4:04         ` John Center
2016-01-02  4:49           ` John Center
2016-01-02 10:35         ` Martin Steigerwald
2016-01-02 11:41           ` Martin Steigerwald
     [not found]             ` <CAPgWCbQE4aJEQ_vR2vu_ad1v2dH6A=50iUSGnQgNeA4Qo68iSQ@mail.gmail.com>
2016-01-03  9:57               ` Martin Steigerwald
2016-01-01 17:41     ` Martin Steigerwald
2016-01-01 18:20       ` John Center
2016-01-01 19:54         ` Martin Steigerwald
     [not found] ` <CAPgWCbTPMqCDx99vBXqFsCAjLzCsnxvCwFQnRfSymbD-_RssMA@mail.gmail.com>
     [not found]   ` <CAPgWCbRZOT-LvECuqgbaHSKWE8mYiO5R9kvk-8BeL-9Lb85fVA@mail.gmail.com>
2016-01-03 10:06     ` Martin Steigerwald [this message]
2016-01-03 22:16       ` John Center
2016-01-03 22:33       ` John Center
2016-01-03 22:43         ` Martin Steigerwald

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=2304914.ebMOxPbdB3@merkaba \
    --to=martin@lichtvoll.de \
    --cc=1i5t5.duncan@cox.net \
    --cc=jlcenter15@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;
as well as URLs for NNTP newsgroup(s).