On 19 September 2015 22:24:19 CEST, Mick <michaelkintz...@gmail.com> wrote: >On Saturday 19 Sep 2015 21:14:00 Stefan G. Weichinger wrote: >> Am 2015-09-18 um 23:58 schrieb Mick: >> >> The main reason for doing a scrub is to detect latent issues, and >> >> if you have redundancy that means you can auto-correct them >> >> today, rather than discovering them a month from now when the >> >> drive containing the only good copy fails. Even if you don't >> >> have redundancy maybe you rotate your backups every 30 days and >> >> detecting the error might mean having the ability to go back and >> >> restore a good copy of the file before it is completely replaced >> >> with bad copies. >> > >> > Thank you Rich, I ran 'btrfs scrub start /" and it found zero >> > problems. dmesg and syslog clean too. >> >> I wrote (= googled something and adapted it a bit) some >> btrfs-scrub.service and .timer for doing that once a week (systemd >> environment): >> >> $ cat btrfs-scrub.service >> [Unit] >> Description=Check volume for errors >> Documentation=man:btrfs-scrub >> After=fstrim.service >> >> [Service] >> Type=oneshot >> ExecStart=/bin/sh -c 'for i in $(grep btrfs /proc/mounts | cut -d" " >> -f1 | sort -u | grep dev); do echo scrubbing $i; btrfs scrub start >-Bd >> $i; done' >> IOSchedulingClass=idle >> CPUSchedulingPolicy=idle >> >> $ cat btrfs-scrub.timer >> [Unit] >> Description=Check volume for errors once a week >> Documentation=man:btrfs-scrub >> >> [Timer] >> OnCalendar=weekly >> AccuracySec=1h >> Persistent=true >> >> [Install] >> WantedBy=timers.target > >Thank you Stefan, I will probably look into doing the same for openrc.
Crontab (or one of its alternatives) would be your friend here. :) -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
