From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Hendrik Friedel <hendrik@friedels.name>,
Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: Broken Filesystem
Date: Sat, 25 Jan 2020 20:20:14 +0800 [thread overview]
Message-ID: <887af814-cec5-494f-80b3-4c2e286dc1b1@gmx.com> (raw)
In-Reply-To: <em16e3d03d-97be-4ddb-b4a4-6a056b469f20@ryzen>
[-- Attachment #1.1: Type: text/plain, Size: 3038 bytes --]
On 2020/1/25 下午7:34, Hendrik Friedel wrote:
> Hello,
>
> I am helping someone here
> https://forum.openmediavault.org/index.php/Thread/29290-Harddrive-Failure-and-Data-Recovery/?postID=226502#post226502
> to recover his data.
> He is new to linux.
>
> Two of his drives have a hardware problem.
> btrfs filesystem show /dev/sda
> Label: 'sdadisk1' uuid: fdce5ae5-fd6d-46b9-8056-3ff15ce9fa16
> Total devices 1 FS bytes used 128.00KiB
> devid 1 size 931.51GiB used 4.10GiB path /dev/sda
>
> The 4.1GiB are way less than what was used.
>
>
> We tried to mount with mount -t btrfs -o recovery,nospace_cache,clear_cache
>
> [Sat Jan 18 11:40:29 2020] BTRFS warning (device sda): 'recovery' is
> deprecated, use 'usebackuproot' instead
> [Sat Jan 18 11:40:29 2020] BTRFS info (device sda): trying to use backup
> root at mount time
> [Sat Jan 18 11:40:29 2020] BTRFS info (device sda): disabling disk space
> caching
> [Sat Jan 18 11:40:29 2020] BTRFS info (device sda): force clearing of
> disk cache
> [Sun Jan 19 11:58:24 2020] BTRFS warning (device sda): 'recovery' is
> deprecated, use 'usebackuproot' instead
> [Sun Jan 19 11:58:24 2020] BTRFS info (device sda): trying to use backup
> root at mount time
> [Sun Jan 19 11:58:24 2020] BTRFS info (device sda): disabling disk space
> caching
> [Sun Jan 19 11:58:24 2020] BTRFS info (device sda): force clearing of
> disk cache
>
>
> The mountpoint does not show any data when mounted
>
> Scrub did not help:
> btrfs scrub start /dev/sda
> scrub started on /dev/sda, fsid fdce5ae5-fd6d-46b9-8056-3ff15ce9fa16
> (pid=19881)
>
> btrfs scrub status /dev/sda
> scrub status for fdce5ae5-fd6d-46b9-8056-3ff15ce9fa16
> scrub started at Sun Jan 19 12:03:35 2020 and finished after 00:00:00
> total bytes scrubbed: 256.00KiB with 0 errors
>
>
> btrfs check /dev/sda
> Checking filesystem on /dev/sda
> UUID: fdce5ae5-fd6d-46b9-8056-3ff15ce9fa16
> checking extents
> checking free space cache
> cache and super generation don't match, space cache will be invalidated
> checking fs roots
> checking csums
> checking root refs
> found 131072 bytes used err is 0
> total csum bytes: 0
> total tree bytes: 131072
> total fs tree bytes: 32768
> total extent tree bytes: 16384
> btree space waste bytes: 123986
> file data blocks allocated: 0
> referenced 0
Your fs is completely fine. I didn't see anything wrong from your `btrfs
check` result nor your kernel messages.
>
>
> Also btrfs restore -i -v /dev/sda /srv/dev-disk-by-label-NewDrive2 | tee
> /restorelog.txt did not help:
> It came immediately back with 'Reached the end of the tree searching the
> directory'
>
>
> btrfs-find-root /dev/sda
> Superblock thinks the generation is 8
> Superblock thinks the level is 0
> It did not finish even in 54 hours
>
> I am out of ideas. Can you give further advice?
Since your fs is OK, what's wrong?
Maybe just mounted wrong subvolume?
Thanks,
Qu
>
> Regards,
> Hendrik
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2020-01-25 12:20 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-25 11:34 Broken Filesystem Hendrik Friedel
2020-01-25 12:20 ` Qu Wenruo [this message]
[not found] ` <emeee471c5-e6f0-4503-8410-742b05f87305@ryzen>
2020-01-25 13:36 ` Qu Wenruo
2020-01-25 15:22 ` Hugo Mills
2020-01-25 19:46 ` Chris Murphy
-- strict thread matches above, loose matches on Subject: below --
2019-02-19 10:24 Broken filesystem Roderick Johnstone
2019-02-19 12:34 ` Qu Wenruo
2019-02-19 12:42 ` Roderick Johnstone
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=887af814-cec5-494f-80b3-4c2e286dc1b1@gmx.com \
--to=quwenruo.btrfs@gmx.com \
--cc=hendrik@friedels.name \
--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;
as well as URLs for NNTP newsgroup(s).