Bug 93401

Summary:	Improper syslog severity level used when btrfs detects corrupt blocks
Product:	File System	Reporter:	OmegaPhil
Component:	btrfs	Assignee:	Josef Bacik (josef)
Status:	RESOLVED PATCH_ALREADY_AVAILABLE
Severity:	low	CC:	dsterba
Priority:	P1
Hardware:	All
OS:	Linux
Kernel Version:	3.16.7-ckt4-3	Subsystem:
Regression:	No	Bisected commit-id:

Description OmegaPhil 2015-02-17 17:16:28 UTC

Debian Testing machine with uname 'Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt4-3 (2015-02-03) x86_64 GNU/Linux'.

Currently when btrfs detects corrupt blocks, messages are logged at the info severity:

=====================================================================

Feb 17 16:42:44 debian-testing-vm kernel: [  601.114836] BTRFS info (device sdb1): csum failed ino 257 off 0 csum 2566472073 expected csum 3494710379
Feb 17 16:42:44 debian-testing-vm kernel: [  601.115240] BTRFS info (device sdb1): csum failed ino 257 off 0 csum 2566472073 expected csum 3494710379

=====================================================================

This is associated with a volume containing a single disk, so the failures are unrecoverable - certainly NOT an acceptable event, and completely missed by scripts which monitor for warning+ messages (tracking this event is basically the whole point of using btrfs for me).

Please can such syslog events be logged at at least the Warning severity - even if the failure is recoverable, it represents a notable failure of the disk (or something inbetween), and isn't just background information. If not by default, perhaps a mount option to configure it?

Thanks

Comment 1 David Sterba 2015-02-17 17:59:43 UTC

Agreed. Patches pending for 3.20.

For the checksum message specifically:

https://patchwork.kernel.org/patch/5521011/ (part of series that updates more log levels).

Comment 2 OmegaPhil 2015-02-17 18:02:07 UTC

Thankyou.