btrfs csum failed, scrub ok
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
Quoted 4 lines · On Tue, 27 Mar 2012 12:57:31 +0200 Christoph Groth <[email protected]> wrote:
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.soThat file seems to be ok, there are no errors when re-reading it.
How about
$ sudo apt-get install debsums $ debsums libreoffice-core | grep libsblx.so
Signature · 8 lines
With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free."
Quoted 6 lines · Roman Mamedov
Quoted 3 lines · On Tue, 27 Mar 2012 12:57:31 +0200 Christoph Groth <[email protected]> wrote:
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
Quoted 6 lines
Quoted 1 line
That file seems to be ok, there are no errors when re-reading it.
How about
$ sudo apt-get install debsums $ debsums libreoffice-core | grep libsblx.so
Good idea!
$ debsums libreoffice-core | grep libsblx.so /usr/lib/libreoffice/basis3.4/program/libsblx.so OK
I'm still puzzled by this incident.
Christoph
Quoted 2 lines · Christoph Groth
I have a freshly installed system with btrfs as the root file system. The machine is running linux 3.2. =C2=A0The raid1 btrfs file system l=
ives on
Quoted 7 lines
two new hard drives.
About one day after installation the following message appeared in kern.log. =C2=A0There 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 4535=
09 off 1495040 csum 3301532933 private 4156998194
Quoted 1 line
Mar 27 01:07:46 mim kernel: [ 6480.234470] btrfs csum failed ino 4535=
09 off 1499136 csum 1873118812 private 3512102188
Quoted 1 line
Mar 27 01:07:46 mim kernel: [ 6480.234572] btrfs csum failed ino 4535=
09 off 1503232 csum 1034640717 private 2041007647
Quoted 1 line
Mar 27 01:07:46 mim kernel: [ 6480.234670] btrfs csum failed ino 4535=
09 off 1507328 csum 889729013 private 2342095239
Quoted 1 line
Mar 27 01:07:46 mim kernel: [ 6480.237977] btrfs csum failed ino 4535=
09 off 1503232 csum 1518679450 private 2041007647
Quoted 1 line
Mar 27 01:07:46 mim kernel: [ 6480.238149] btrfs csum failed ino 4535=
09 off 1507328 csum 889729013 private 2342095239
Quoted 1 line
Mar 27 01:07:46 mim kernel: [ 6480.238330] btrfs csum failed ino 4535=
09 off 1495040 csum 3234580989 private 4156998194
Quoted 1 line
Mar 27 01:07:46 mim kernel: [ 6480.238447] btrfs csum failed ino 4535=
09 off 1499136 csum 1873118812 private 3512102188
Quoted 1 line
Mar 27 01:07:46 mim kernel: [ 6480.243873] btrfs csum failed ino 4535=
09 off 1503232 csum 2184012753 private 2041007647
Quoted 1 line
Mar 27 01:07:46 mim kernel: [ 6480.243962] btrfs csum failed ino 4535=
09 off 1507328 csum 240604621 private 2342095239
Quoted 5 lines
inode 453509 belongs to a file installed by dpkg
root@mim:/# find / -inum 453509 -ls 453509 1976 -rw-r--r-- =C2=A0 1 root =C2=A0 =C2=A0 root =C2=A0 =C2=A0=
=C2=A02020832 Mar =C2=A07 21:11 /usr/lib/libreoffice/basis3.4/program/=
libsblx.so
Quoted 9 lines
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 =C2=A0 =C2=A0 =C2=A0 =C2=A0scrub started at Tue Mar 27 10:37:49 2012 =
and finished after 3921 seconds
Quoted 1 line
=C2=A0 =C2=A0 =C2=A0 =C2=A0total bytes scrubbed: 550.20GB with 0 erro=
rs
If btrfs is able to find a good copy, it will fix the bad copy automati= cally.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 10 lines · cwillu
Quoted 7 lines · Christoph Groth
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 errorsIf btrfs is able to find a good copy, it will fix the bad copy automatically.
It does mention this in your logs, though. Grep for "repair", if it doesn't occur, btrfs didn't repair any failures.
Scrub would normally find and count checksum errors, though.
-Jan
Quoted 10 lines · Jan Schmidt
Quoted 9 lines · cwillu
Quoted 7 lines · Christoph Groth
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
Quoted 4 lines
Quoted 1 line
If btrfs is able to find a good copy, it will fix the bad copy automatically.
It does mention this in your logs, though. Grep for "repair", if it doesn't occur, btrfs didn't repair any failures.
"repair" doesn't occur in the logs. Actually, there are no other entries from btrfs.
So why didn't btrfs try to repair a block it believed to be bad?