From: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
To: Mike Hartman <mike@hartmanipulation.com>
Cc: Chris Murphy <lists@colorremedies.com>, <linux-btrfs@vger.kernel.org>
Subject: Re: Btrfs suddenly unmountable, open_ctree failed
Date: Tue, 24 Jun 2014 11:09:31 +0800 [thread overview]
Message-ID: <53A8EBEB.1030702@cn.fujitsu.com> (raw)
In-Reply-To: <CAB=7dhm4wz7tXm7am0ezNvAiH+YjKBYrL53AQsn9DMQJwaus4Q@mail.gmail.com>
Hi Mike,
On 06/24/2014 11:04 AM, Mike Hartman wrote:
> I have no particular desire to use it. I just tried everything else
> first and thought it was worth a shot.
>
> If you think that version would help, can you point me to the git
> repo? The one I grabbed was
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs.git.
Of course, You could pull from the following url:
https://github.com/kdave/btrfs-progs.git integration-20140619
>
> On Mon, Jun 23, 2014 at 10:20 PM, Wang Shilong
> <wangsl.fnst@cn.fujitsu.com> wrote:
>> On 06/24/2014 09:17 AM, Chris Murphy wrote:
>>> On Jun 23, 2014, at 4:18 PM, Mike Hartman <mike@hartmanipulation.com>
>>> wrote:
>>>
>>>> Can anyone offer any suggestions? Is this data really unrecoverable? I
>>>> have no idea what could have gone so severely wrong.
>>> "btrfs check --repair /media/mint/usb_data/sda6_check.img
>>> "btrfs check --repair --init-csum-tree --init-extent-tree
>>> /media/mint/usb_data/sda6_check.img
>> My two cents:-)
>>
>> If you really want to use btrfs check --init-csum-tree --init-extent-tree,
>> i'd suggest you use
>> David Latest btrfs-progs branch which includes some latest bug fixes.
>>
>>> I think these things are going too far on actual file system without
>>> guidance, so it's superb you imaged the original drive first. Too many
>>> people get aggressive writing to the actual drive without backup images. You
>>> have both a dd image as well as btrfs-image which is really great. Hopefully
>>> someone can help find out what happened, it seems abruptly catastrophic, but
>>> also mixes messages where some information is being found but this one:
>>> * read block failed check_tree_block
>>> makes me think of partial media failure. It would be damn bad luck if your
>>> metadata is set to DUP, yet both copies are toast. Is this an HDD or SSD?
>>>
>>> Can you post the result from smartctl -x /dev/sdX #for the disk in
>>> question, maybe from a live system?
>>>
>>>
>>> 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-06-24 3:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-23 22:18 Btrfs suddenly unmountable, open_ctree failed Mike Hartman
2014-06-24 1:17 ` Chris Murphy
2014-06-24 2:20 ` Wang Shilong
2014-06-24 3:04 ` Mike Hartman
2014-06-24 3:09 ` Wang Shilong [this message]
2014-06-24 5:39 ` Mike Hartman
2014-06-24 15:40 ` Chris Murphy
2014-06-24 2:58 ` Mike Hartman
2014-06-24 4:15 ` Chris Murphy
2014-06-24 4:49 ` Mike Hartman
[not found] ` <CAB=7dhms_ehP4y+L_tMBrdUnJiwXAOn7E4Fa9u3euVBwBKHOKA@mail.gmail.com>
2014-06-24 5:19 ` Chris Murphy
2014-06-24 5:49 ` Mike Hartman
2014-06-24 16:15 ` Chris Murphy
2014-06-25 5:53 ` Mike Hartman
2014-06-25 18:38 ` Chris Murphy
2014-06-25 19:32 ` Mike Hartman
2014-06-25 19:50 ` Chris Murphy
2014-06-24 10:00 ` Duncan
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=53A8EBEB.1030702@cn.fujitsu.com \
--to=wangsl.fnst@cn.fujitsu.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=lists@colorremedies.com \
--cc=mike@hartmanipulation.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.