[clug] Is a weekly RAID scrub too much?
rodneyp at iinet.net.au
Mon Feb 27 23:35:03 UTC 2017
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.
Thanks for that assistance. Results are a little informative plus
for the workstation, which runs some BTRFS on an aging Samsung 1 TB
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
More information about the linux