From: Oliver Mangold <o.mangold@gmail.com>
To: linux-btrfs@vger.kernel.org
Subject: Re: coredump in btrfsck
Date: Wed, 01 Jan 2014 23:35:24 +0100 [thread overview]
Message-ID: <52C4982C.1040606@gmail.com> (raw)
In-Reply-To: <45E0985F-4F75-47D1-BD6E-2286D5844AE3@colorremedies.com>
On 01.01.2014 22:58, Chris Murphy wrote:
> On Jan 1, 2014, at 2:27 PM, Oliver Mangold <o.mangold@gmail.com> wrote:
>
>> I fear, I broke my FS by running btrfsck. I tried 'btrfsck --repair' and it fixed several problems but finally crashed with some debug message from 'extent-tree.c', so I also tried 'btrfsck --repair --init-extent-tree'.
> It is sort of a (near) last restort, you know this right? What did you try before btrfsck? Did you set dmesg -n7, then mount -o recovery and if so what was recorded in dmesg?
Ehm, actually, no. Before I ran btrfsck there was no reason to use '-o
recovery' or something, because the filesystem seemed to work. But I was
worried after running btrfsck, because the FS apparently was in an
inconsistent state. So I tried 'btrfsck --repair' and when that crashed
'btrfsck --init-extent-tree'. Didn't know it is considered 'last
resort'. It did the trick for several previous problems and seemed to
have no negative consequences, so I tried it now also.
But it looks like I can still recover my data with 'btrfs restore', so
it's less critical than assumed.
Sorry, that I can't give you the logs you would have liked. Didn't
expect anything bad to happen. I would just wsh that btrfsck could fix
that kind of problem. Let me know if I can help.
>> produces log messages:
>>
>> Jan 01 21:45:09 home kernel: btrfs: device fsid 31a5d433-4f7b-49cc-9bc0-9422471f5194 devid 1 transid 4793 /dev/mapper/primary-home
>> Jan 01 21:45:09 home kernel: btrfs: disk space caching is enabled
>> Jan 01 21:45:09 home kernel: parent transid verify failed on 2176851968 wanted 4792 found 4793
>> Jan 01 21:45:09 home kernel: parent transid verify failed on 2176851968 wanted 4792 found 4793
>> Jan 01 21:45:09 home kernel: btrfs: open_ctree failed
> If you previously tried -o recovery, before btrfsck did you try btrfs-zero-log and if so what were the results in console and in dmesg?
>
>
> Chris Murphy
>
> --
> 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
next prev parent reply other threads:[~2014-01-01 22:35 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-01 21:27 coredump in btrfsck Oliver Mangold
2014-01-01 21:58 ` Chris Murphy
2014-01-01 22:35 ` Oliver Mangold [this message]
2014-01-02 17:37 ` Chris Murphy
2014-01-03 12:33 ` Marc MERLIN
2014-01-04 0:14 ` Chris Murphy
2014-01-05 6:13 ` Marc MERLIN
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=52C4982C.1040606@gmail.com \
--to=o.mangold@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 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.