Re: Corrupted files support needed

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

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



On 2019/4/17 下午7:16, Daniel Brunner wrote:
> Hi again,
> 
> the check went through,
> and no errors were reported...
> 
> I tried mounting the fs again,
> and suddenly all read errors disappeared!

Then there should be something wrong with the disc connection (but why
block layer doesn't complain?)

> 
> A full copy is already running,
> and after that i will nuke it from orbit.
> 
> Thank you all for the quick answers,
> I do not completely understand what exactly was going wrong,
> but I am confident that the files are not corrupted anymore (I checked
> a few random ones).

As long as btrfs doesn't report checksum error and your memory is not
faulty, btrfs should ensure all your data is correct.

Glad your problem just disappeared.

Thanks,
Qu

> 
> -- Daniel
> 
> (output of the check)
> # btrfs check --readonly /dev/mapper/sde-open
> Opening filesystem to check...
> Checking filesystem on /dev/mapper/sde-open
> UUID: 26a3ef79-15ba-4041-951b-284fbbe08074
> [1/7] checking root items
> [2/7] checking extents
> [3/7] checking free space cache
> [4/7] checking fs roots
> [5/7] checking only csums items (without verifying data)
> [6/7] checking root refs
> [7/7] checking quota groups skipped (not enabled on this FS)
> found 50094867738635 bytes used, no error found
> total csum bytes: 48133927932
> total tree bytes: 60644540416
> total fs tree bytes: 4307402752
> total extent tree bytes: 1874182144
> btree space waste bytes: 6642842911
> file data blocks allocated: 50464303362048
>  referenced 49273323020288
> 
> Am Di., 16. Apr. 2019 um 10:00 Uhr schrieb Roman Mamedov <rm@romanrm.net>:
>>
>> On Tue, 16 Apr 2019 09:46:39 +0200
>> Daniel Brunner <daniel@brunner.ninja> wrote:
>>
>>> Hi,
>>>
>>> thanks for the quick response.
>>>
>>> The filesystem went read-only on its own right at the first read error.
>>> 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.
>>>
>>> Does it make sense to let it run until the end or can I assume that 2
>>> drives are bad?
>>> Also I checked SMART values but they seem to be ok.
>>>
>>> https://0x0.st/zNg6.log
>>
>> ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
>> 190 Airflow_Temperature_Cel 0x0022   047   031   040    Old_age   Always   In_the_past 53 (Min/Max 47/53 #5115)
>>
>> This seems to be normalized as VALUE=100-RAW_VALUE by the SMART firmware, and
>> looking at the reading in WORST, indicates that some of your drives earlier
>> have seen temperatures of as high as 69 C.
>>
>> This is insanely hot to run your drives at, I'd say to the point of "shut off
>> everything ASAP via the mains breaker to avoid immediate permanent damage";
>>
>> Not sure if it's related to the csum errors at hand, but it very well might be.
>>
>> Even the current temps of 55-60 are about 15-20 degrees higher than ideal.
>>
>> --
>> With respect,
>> Roman


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