On 2020/1/25 下午9:32, Hendrik Friedel wrote: > Hello, > > thanks for your reply. > The problem is, that no data is shown after mounting. Furthermore > devid 1 size 931.51GiB used 4.10GiB path /dev/sda > The disk was almost full. Now 4.1GiB seem to be used only. Then it looks like related subvolumes get deleted. Without some exotic method like `btrfs-find-root` there is no way to locate deleted subvolume data. Thanks, Qu > > Greetings, > Hendrik > > ------ Originalnachricht ------ > Von: "Qu Wenruo" <quwenruo.btrfs@xxxxxxx <mailto:quwenruo.btrfs@xxxxxxx>> > An: "Hendrik Friedel" <hendrik@xxxxxxxxxxxxx > <mailto:hendrik@xxxxxxxxxxxxx>>; "Btrfs BTRFS" > <linux-btrfs@xxxxxxxxxxxxxxx <mailto:linux-btrfs@xxxxxxxxxxxxxxx>> > Gesendet: 25.01.2020 13:20:14 > Betreff: Re: Broken Filesystem > >> >> >> 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:
signature.asc
Description: OpenPGP digital signature
