[clug] Is a weekly RAID scrub too much?

[Rodney Peters]

On 27/02/17 22:28, Paul Wayper wrote:
> On 27/02/17 11:05, Rodney Peters wrote:
>> Perhaps not quickly.  I do run BTRFS, although on a systemd system and might
>> need a bit of reading to figure out what the equivalent grep phrase would be.
> journalctl --no-pager | grep "csum failed ino"
>
> I'm not sure from journalctl's man page what a 'SYSLOG IDENTIFIER' is, but if
> 'csum failed ino' is one you could do:
>
> journalctl --no-pager -t 'csum failed ino'
>
> I don't know if these are generated by the kernel or by btrfsd or some other
> unit; once we know what unit is involved you could use -u btrfs or similar.
>
> HTH,
>
> Paul
>
Thanks for that assistance.  Results are a little informative plus 
encouraging:

for the workstation, which runs some BTRFS on an aging Samsung 1 TB 
consumer-grade HDD:

jw870:~ # journalctl --no-pager | grep "csum failed ino"
Failed to get journal fields: Bad message
jw870:~ # journalctl --no-pager -t 'csum failed ino'
-- No entries --

for the micro-server, which runs BTRFS only on the root file system on a 
HP 250 GB drive that is several years old, although probably intended 
for continuous use:

n36l:~ # journalctl --no-pager -t 'csum failed ino'
-- No entries --

These systems were built at a time when SuSE/Novell were recommending 
BTRFS for system, but not data, partitions.  So, BTRFS is a relatively 
small, although heavily used area of the HDD.  I do also use it for KVM 
VM, but that is a "sandbox" to me.

I do have a couple of "off-site" backup drives that have BTRFS only for 
archive partitions.  Those don't see a lot of power-up time and aren't 
likely to show the sort of errors that Eyal is experiencing.

Clearly we need to spend a bit more time with "man journalctl", if we 
want to pursue this

Cheers,

Rod