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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox