From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cn.fujitsu.com ([59.151.112.132]:16579 "EHLO heian.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751144AbaFXCYq convert rfc822-to-8bit (ORCPT ); Mon, 23 Jun 2014 22:24:46 -0400 Message-ID: <53A8E079.1060803@cn.fujitsu.com> Date: Tue, 24 Jun 2014 10:20:41 +0800 From: Wang Shilong MIME-Version: 1.0 To: Chris Murphy , Mike Hartman CC: Subject: Re: Btrfs suddenly unmountable, open_ctree failed References: In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 06/24/2014 09:17 AM, Chris Murphy wrote: > On Jun 23, 2014, at 4:18 PM, Mike Hartman 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 >