Re: Corrupted files support needed

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3116 bytes --]



On 2019/4/16 下午3:46, Daniel Brunner wrote:
> Hi,
> 
> thanks for the quick response.
> 
> The filesystem went read-only on its own right at the first read error.

Then the fs metadata should get corrupted.

> I unmounted all mounts and rebooted (just to be sure).
> 
> I ran the command you suggested with --progress
> All output is flushed away with thousands of lines like those at the
> end of the log paste.

Then please stop that running command, as it won't help much.

Regular "btrfs check --readonly" should be able to report the metadata
corruption.

> 
> Does it make sense to let it run until the end or can I assume that 2
> drives are bad?

No need to continue, there should be some metadata corruption.

Above command should report something.

For the device corruption part, I'm not sure. But I think there is
definitely something wrong.

Please start salvage your data, as I'm afraid the fs is already damaged,
although not sure how serious it is.

Thanks,
Qu

> Also I checked SMART values but they seem to be ok.
> 
> https://0x0.st/zNg6.log
> 
> -- Daniel
> 
> Am Mo., 15. Apr. 2019 um 13:58 Uhr schrieb Qu Wenruo <quwenruo.btrfs@gmx.com>:
>>
>>
>>
>> On 2019/4/15 下午7:44, Daniel Brunner wrote:
>>> Hi,
>>>
>>> after normal a reboot I noticed that many files fail to open / read
>>> (Input/Output error). I don't really have a backup of it (only
>>> snapshots which also seem to be corrupted too).
>>> The machine is remote, I can only ssh into it (at the moment). The
>>> raid consists of 8x 10TB drives.
>>>
>>> System & Metadata is RAID1
>>> Data is RAID6
>>>
>>> kernel is the most recent from arch linux repositories:
>>> 5.0.7-arch1-1-ARCH #1 SMP PREEMPT Mon Apr 8 10:37:08 UTC 2019 x86_64 GNU/Linux
>>>
>>> Disk layout & usage:
>>> https://0x0.st/zNBl.log
>>>
>>> Output of btrfs check:
>>> https://0x0.st/zNJs.log
>>
>> Strange, btrfs check reports no error at all.
>>
>> Would you please try btrfs check unmounted just in case.
>>
>>>
>>> Kernel messages:
>>> http://cwillu.com:8080/84.115.44.105/2
>>
>> According to the dmesg, it looks like one device is bad, affecting both
>> data and metadata.
>>
>> And thanks to recent RAID6 enhancement to try all possible mirror
>> combination, it doesn't cause too many problem to metadata at least.
>>
>> Although data csum is not that good.
>> Quite a lot of combination doesn't match checksum, and even more, some
>> check doesn't exist in csum tree.
>>
>> An unmounted btrfs check is recommended.
>> # btrfs check --check-data-csum --readonly
>>
>> This would be better than scrub.
>>
>> And please check the SMART info, some devices look suspicious.
>>
>> Also, please remount the fs read only at least to prevent further
>> corruption.
>>
>> Thanks,
>> Qu
>>
>>>
>>> btrfs scrub is running but it seems like it will take weeks to finish...
>>>
>>> Do you think my data is gone or is there anything I can try? An rsync
>>> is already running, but every 5th file fails to read.
>>>
>>> Best regards,
>>> Daniel
>>>
>>


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]