| 1 |
Am 2015-09-18 um 23:58 schrieb Mick: |
| 2 |
|
| 3 |
>> The main reason for doing a scrub is to detect latent issues, and |
| 4 |
>> if you have redundancy that means you can auto-correct them |
| 5 |
>> today, rather than discovering them a month from now when the |
| 6 |
>> drive containing the only good copy fails. Even if you don't |
| 7 |
>> have redundancy maybe you rotate your backups every 30 days and |
| 8 |
>> detecting the error might mean having the ability to go back and |
| 9 |
>> restore a good copy of the file before it is completely replaced |
| 10 |
>> with bad copies. |
| 11 |
> |
| 12 |
> Thank you Rich, I ran 'btrfs scrub start /" and it found zero |
| 13 |
> problems. dmesg and syslog clean too. |
| 14 |
|
| 15 |
I wrote (= googled something and adapted it a bit) some |
| 16 |
btrfs-scrub.service and .timer for doing that once a week (systemd |
| 17 |
environment): |
| 18 |
|
| 19 |
$ cat btrfs-scrub.service |
| 20 |
[Unit] |
| 21 |
Description=Check volume for errors |
| 22 |
Documentation=man:btrfs-scrub |
| 23 |
After=fstrim.service |
| 24 |
|
| 25 |
[Service] |
| 26 |
Type=oneshot |
| 27 |
ExecStart=/bin/sh -c 'for i in $(grep btrfs /proc/mounts | cut -d" " |
| 28 |
-f1 | sort -u | grep dev); do echo scrubbing $i; btrfs scrub start -Bd |
| 29 |
$i; done' |
| 30 |
IOSchedulingClass=idle |
| 31 |
CPUSchedulingPolicy=idle |
| 32 |
|
| 33 |
$ cat btrfs-scrub.timer |
| 34 |
[Unit] |
| 35 |
Description=Check volume for errors once a week |
| 36 |
Documentation=man:btrfs-scrub |
| 37 |
|
| 38 |
[Timer] |
| 39 |
OnCalendar=weekly |
| 40 |
AccuracySec=1h |
| 41 |
Persistent=true |
| 42 |
|
| 43 |
[Install] |
| 44 |
WantedBy=timers.target |
Archives