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@gmx.com <mailto:quwenruo.btrfs@gmx.com>>
> An: "Hendrik Friedel" <hendrik@friedels.name
> <mailto:hendrik@friedels.name>>; "Btrfs BTRFS"
> <linux-btrfs@vger.kernel.org <mailto:linux-btrfs@vger.kernel.org>>
> 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
>>>  
>>