From: "Dmitriy Perlow" <dap@open.by>
To: linux-btrfs@vger.kernel.org, "Qu Wenruo" <quwenruo@cn.fujitsu.com>
Subject: Re: Any help to restore broken partition?
Date: Mon, 12 Jan 2015 06:59:52 +0300 [thread overview]
Message-ID: <op.xsbz12d2odbuyo@darkness> (raw)
In-Reply-To: <54B328F0.4010207@cn.fujitsu.com>
[-- Attachment #1: Type: text/plain, Size: 4308 bytes --]
Qu Wenruo <quwenruo@cn.fujitsu.com> Mon, 12 Jan 2015 04:52:48 +0300:
> Hi,
> -------- Original Message --------
> Subject: Any help to restore broken partition?
> From: Dmitriy Perlow <dap@open.by>
> To: <linux-btrfs@vger.kernel.org>
> Date: 2015年01月12日 03:59
>> Hi to all!
>>
>> I've been using btrfs at my /home partition without any problems for
>> about
>> 3 years but today it was made read only. I umounted it and executed
>> `btrfs
>> check --repair` and got lots of errors.
> Did you saved all the outputs of the btrfsck --repair?
No, sorry.
>> I run openSUSE 13.1 x64 with linux 3.11.10, Btrfs v3.18+20141230.
> Kernel is somewhat old, but btrfs-progs is new enough for possible
> recovery.
>>
>> # btrfs fi show
>> Label: none uuid: 96e5c775-86b2-4dd9-a671-fe9a343cc10b
>> Total devices 1 FS bytes used 5.35GiB
>> devid 1 size 10.85GiB used 10.85GiB path /dev/sda3
> Size seems small enough to do a full dd backup.
> Better to do it in case btrfsck --repair makes things worse.
> But it seems too late for your case.... it should be done before any
> 'btrfs check --repair'
>
> Also, you can use btrfs-image to do a backup, which should be much
> smaller than dd dump,
> at the cost of no data dumped
> (mainly used for dev purpose, like to check btrfsck works as expected or
> not,
> and since it contains no data but only metadata, it should be somewhat
> OK to send it to developers)
Attached.
> If it's OK for you, it would be better to dump the driver with "-c9"
> option and send it to us for better test.
>
>>
>> # mount -o ro,recovery /home
>> → no directories except of lost+found.
> And what's inside that dir?
-rwx------ 1 root root 0 2015-01-11 23:23 1103101952
-rwx------ 1 root root 0 2015-01-11 23:23 12582912
-rwx------ 1 root root 0 2015-01-11 23:23 20971520
-rwx------ 1 root root 0 2015-01-11 23:23 2176843776
-rwx------ 1 root root 0 2015-01-11 23:23 29360128
-rwx------ 1 root root 0 2015-01-11 23:23 29368320
-rwx------ 1 root root 0 2015-01-11 23:23 29380608
-rwx------ 1 root root 0 2015-01-11 23:23 29384704
-rwx------ 1 root root 0 2015-01-11 23:23 3250585600
-rwx------ 1 root root 0 2015-01-11 23:23 4194304
-rwx------ 1 root root 0 2015-01-11 23:23 4324327424
-rwx------ 1 root root 0 2015-01-11 23:23 5398069248
-rwx------ 1 root root 0 2015-01-11 23:23 6471811072
-rwx------ 1 root root 0 2015-01-11 23:23 7545552896
-rwx------ 1 root root 0 2015-01-11 23:23 8619294720
-rwx------ 1 root root 0 2015-01-11 23:23 9693036544
>> # btrfs check /dev/sda3
>> Checking filesystem on /dev/sda3
>> UUID: 96e5c775-86b2-4dd9-a671-fe9a343cc10b
>> checking extents
>> Block Group[0, 4194304] existed.
>> Block Group[4194304, 8388608] existed.
>> Block Group[12582912, 8388608] existed.
>> Block Group[20971520, 8388608] existed.
>> Block Group[29360128, 1073741824] existed.
>> Block Group[1103101952, 1073741824] existed.
>> Block Group[2176843776, 1073741824] existed.
>> Block Group[3250585600, 1073741824] existed.
>> Block Group[4324327424, 1073741824] existed.
>> Block Group[5398069248, 1073741824] existed.
>> Block Group[6471811072, 1073741824] existed.
>> Block Group[7545552896, 1073741824] existed.
>> Block Group[8619294720, 1073741824] existed.
>> Block Group[9693036544, 874512384] existed.
> Seems only block group problems. --init-extent-tree may helps.
> WARNING: Do it *AFTER* a full backup or do it on a btrfs-image restored
> backup!!
It didn't.
>> Errors found in extent allocation tree or chunk allocation
>> checking free space cache
>> cache and super generation don't match, space cache will be invalidated
>> checking fs roots
>> checking csums
>> checking root refs
> Other things seems good.
> Seems btrfsck --repair did the job, hoping your btrfs-progs has the
> patch to fix a bug that
> may delete all the repaired files...
>
> Thanks,
> Qu
>>
>> found 36864 bytes used err is 0
>> total csum bytes: 0
>> total tree bytes: 20480
>> total fs tree bytes: 8192
>> total extent tree bytes: 4096
>> btree space waste bytes: 15135
>> file data blocks allocated: 0
>> referenced 0
>>
>>
>> Any help please?
--
Best regards,
Dmitriy DA(P).DarkneSS Perlow @ Linux x64
[-- Attachment #2: btrfsimage --]
[-- Type: application/octet-stream, Size: 37888 bytes --]
next prev parent reply other threads:[~2015-01-12 4:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-11 19:59 Any help to restore broken partition? Dmitriy Perlow
2015-01-12 1:52 ` Qu Wenruo
2015-01-12 3:59 ` Dmitriy Perlow [this message]
2015-01-12 4:20 ` Qu Wenruo
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=op.xsbz12d2odbuyo@darkness \
--to=dap@open.by \
--cc=linux-btrfs@vger.kernel.org \
--cc=quwenruo@cn.fujitsu.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 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).