From: Christoph Groth <cwg@falma.de>
To: linux-btrfs@vger.kernel.org
Subject: btrfs csum failed, scrub ok
Date: Tue, 27 Mar 2012 12:57:31 +0200 [thread overview]
Message-ID: <87haxawbtw.fsf@falma.de> (raw)
I have a freshly installed system with btrfs as the root file system.
The machine is running linux 3.2. The raid1 btrfs file system lives on
two new hard drives.
About one day after installation the following message appeared in
kern.log. There were no other errors.
root@mim:/var/log# grep 'btrfs.*fail' kern.log
Mar 27 01:07:46 mim kernel: [ 6480.233861] btrfs csum failed ino 453509 off 1495040 csum 3301532933 private 4156998194
Mar 27 01:07:46 mim kernel: [ 6480.234470] btrfs csum failed ino 453509 off 1499136 csum 1873118812 private 3512102188
Mar 27 01:07:46 mim kernel: [ 6480.234572] btrfs csum failed ino 453509 off 1503232 csum 1034640717 private 2041007647
Mar 27 01:07:46 mim kernel: [ 6480.234670] btrfs csum failed ino 453509 off 1507328 csum 889729013 private 2342095239
Mar 27 01:07:46 mim kernel: [ 6480.237977] btrfs csum failed ino 453509 off 1503232 csum 1518679450 private 2041007647
Mar 27 01:07:46 mim kernel: [ 6480.238149] btrfs csum failed ino 453509 off 1507328 csum 889729013 private 2342095239
Mar 27 01:07:46 mim kernel: [ 6480.238330] btrfs csum failed ino 453509 off 1495040 csum 3234580989 private 4156998194
Mar 27 01:07:46 mim kernel: [ 6480.238447] btrfs csum failed ino 453509 off 1499136 csum 1873118812 private 3512102188
Mar 27 01:07:46 mim kernel: [ 6480.243873] btrfs csum failed ino 453509 off 1503232 csum 2184012753 private 2041007647
Mar 27 01:07:46 mim kernel: [ 6480.243962] btrfs csum failed ino 453509 off 1507328 csum 240604621 private 2342095239
inode 453509 belongs to a file installed by dpkg
root@mim:/# find / -inum 453509 -ls
453509 1976 -rw-r--r-- 1 root root 2020832 Mar 7 21:11 /usr/lib/libreoffice/basis3.4/program/libsblx.so
That file seems to be ok, there are no errors when re-reading it.
A scrub done the morning after the incident also didn't find any
problems:
root@mim:/home/cwg# btrfs scrub status /
scrub status for 2da00153-f9ea-4d6c-a6cc-10c913d22686
scrub started at Tue Mar 27 10:37:49 2012 and finished after 3921 seconds
total bytes scrubbed: 550.20GB with 0 errors
Also inspecting the SMART status of the hard drives does not reveal any
problems.
Is this a bug in btrfs, or am I supposed to be afraid that the new hard
drives are not working reliably? Or could this be the effect of some
cosmic ray hitting my machine? (It doesn't have ECC.) Or is it normal
that hard drives sometimes make errors? (In that case the additional
layer of btrfs checksumming seems to be a very good thing.)
Christoph
next reply other threads:[~2012-03-27 10:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-27 10:57 Christoph Groth [this message]
2012-03-27 11:08 ` btrfs csum failed, scrub ok Roman Mamedov
2012-03-27 11:55 ` Christoph Groth
2012-03-27 16:24 ` cwillu
2012-03-27 16:46 ` Jan Schmidt
2012-03-27 16:59 ` Christoph Groth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87haxawbtw.fsf@falma.de \
--to=cwg@falma.de \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.