W dniu 26.12.2019 o 23:15, Chris Murphy pisze:
>
> What is the SCT ERC for each drive?
Failing drive is /dev/sda.
root@wawel:~# smartctl -l scterc /dev/sda
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.19.0-6-amd64] (local
build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke,
www.smartmontools.org
SCT Error Recovery Control command not supported
root@wawel:~# smartctl -l scterc /dev/sdb
SCT Error Recovery Control:
Read: 70 (7.0 seconds)
Write: 70 (7.0 seconds)
root@wawel:~# smartctl -l scterc /dev/sdc
SCT Error Recovery Control:
Read: 100 (10.0 seconds)
Write: 100 (10.0 seconds)
I have changed timeout to higher:
echo 180 > /sys/block/sda/device/timeout
> And when was the last time a scrub was done on the volume?
It was done few months ago unfortunatelly...
> Were there
> any errors reported by either user space tools or kernel? And what
> were they?
There were NO errors from any user space tools.
Only smartctl reported uncorrectable sectors and failed smart self-tests.
Thank you for suggestions below. Data is not critical (this is backup
server...).
I will see tommorow how is the progress.
Actually there are no errors but this is slow only...
> My suggestion for single profile multiple device is to leave the per
> drive SCT ERC disabled (or a high value, e.g. 1200 deciseconds) and
> also change the per block device command timer (this is a kernel timer
> set per device) to be at least 120 seconds.
> This will allow the drive
> to do deep recovery, which will make it dog slow, but if necessary
> it'll improve the chances of getting data off the drives. If you don't
> care about getting data off the drives, i.e. you have a backup, then
> you can set the SCT ERC value to 70 deciseconds. Any bad sector errors
> will quickly result in a read error, Btrfs will report the affected
> file. IF it's metadata that's affected, it'll get a good copy from the
> mirror, and fix up the bad copy, automatically.
>
>
>
