* btrfs csum failed, scrub ok
@ 2012-03-27 10:57 Christoph Groth
2012-03-27 11:08 ` Roman Mamedov
2012-03-27 16:24 ` cwillu
0 siblings, 2 replies; 6+ messages in thread
From: Christoph Groth @ 2012-03-27 10:57 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs csum failed, scrub ok
2012-03-27 10:57 btrfs csum failed, scrub ok Christoph Groth
@ 2012-03-27 11:08 ` Roman Mamedov
2012-03-27 11:55 ` Christoph Groth
2012-03-27 16:24 ` cwillu
1 sibling, 1 reply; 6+ messages in thread
From: Roman Mamedov @ 2012-03-27 11:08 UTC (permalink / raw)
To: Christoph Groth; +Cc: linux-btrfs
[-- Attachment #1: Type: text/plain, Size: 569 bytes --]
On Tue, 27 Mar 2012 12:57:31 +0200
Christoph Groth <cwg@falma.de> 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
>
> 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
--
With respect,
Roman
~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Stallman had a printer,
with code he could not see.
So he began to tinker,
and set the software free."
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs csum failed, scrub ok
2012-03-27 11:08 ` Roman Mamedov
@ 2012-03-27 11:55 ` Christoph Groth
0 siblings, 0 replies; 6+ messages in thread
From: Christoph Groth @ 2012-03-27 11:55 UTC (permalink / raw)
To: linux-btrfs
Roman Mamedov <rm@romanrm.ru> writes:
> On Tue, 27 Mar 2012 12:57:31 +0200
> Christoph Groth <cwg@falma.de> 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
>>
>> 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs csum failed, scrub ok
2012-03-27 10:57 btrfs csum failed, scrub ok Christoph Groth
2012-03-27 11:08 ` Roman Mamedov
@ 2012-03-27 16:24 ` cwillu
2012-03-27 16:46 ` Jan Schmidt
1 sibling, 1 reply; 6+ messages in thread
From: cwillu @ 2012-03-27 16:24 UTC (permalink / raw)
To: Christoph Groth; +Cc: linux-btrfs
On Tue, Mar 27, 2012 at 4:57 AM, Christoph Groth <cwg@falma.de> wrote:
> 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
> 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
> Mar 27 01:07:46 mim kernel: [ 6480.234470] btrfs csum failed ino 4535=
09 off 1499136 csum 1873118812 private 3512102188
> Mar 27 01:07:46 mim kernel: [ 6480.234572] btrfs csum failed ino 4535=
09 off 1503232 csum 1034640717 private 2041007647
> Mar 27 01:07:46 mim kernel: [ 6480.234670] btrfs csum failed ino 4535=
09 off 1507328 csum 889729013 private 2342095239
> Mar 27 01:07:46 mim kernel: [ 6480.237977] btrfs csum failed ino 4535=
09 off 1503232 csum 1518679450 private 2041007647
> Mar 27 01:07:46 mim kernel: [ 6480.238149] btrfs csum failed ino 4535=
09 off 1507328 csum 889729013 private 2342095239
> Mar 27 01:07:46 mim kernel: [ 6480.238330] btrfs csum failed ino 4535=
09 off 1495040 csum 3234580989 private 4156998194
> Mar 27 01:07:46 mim kernel: [ 6480.238447] btrfs csum failed ino 4535=
09 off 1499136 csum 1873118812 private 3512102188
> Mar 27 01:07:46 mim kernel: [ 6480.243873] btrfs csum failed ino 4535=
09 off 1503232 csum 2184012753 private 2041007647
> Mar 27 01:07:46 mim kernel: [ 6480.243962] btrfs csum failed ino 4535=
09 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-- =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
>
> 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
> =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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs csum failed, scrub ok
2012-03-27 16:24 ` cwillu
@ 2012-03-27 16:46 ` Jan Schmidt
2012-03-27 16:59 ` Christoph Groth
0 siblings, 1 reply; 6+ messages in thread
From: Jan Schmidt @ 2012-03-27 16:46 UTC (permalink / raw)
To: cwillu, Christoph Groth; +Cc: linux-btrfs
On 27.03.2012 18:24, cwillu wrote:
> On Tue, Mar 27, 2012 at 4:57 AM, Christoph Groth <cwg@falma.de> wrote:
>> 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
>
> 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.
Scrub would normally find and count checksum errors, though.
-Jan
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: btrfs csum failed, scrub ok
2012-03-27 16:46 ` Jan Schmidt
@ 2012-03-27 16:59 ` Christoph Groth
0 siblings, 0 replies; 6+ messages in thread
From: Christoph Groth @ 2012-03-27 16:59 UTC (permalink / raw)
To: linux-btrfs
Jan Schmidt <list.btrfs@jan-o-sch.net> writes:
> On 27.03.2012 18:24, cwillu wrote:
>> On Tue, Mar 27, 2012 at 4:57 AM, Christoph Groth <cwg@falma.de> wrote:
>>> 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
>>
>> 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?
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-03-27 16:59 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-03-27 10:57 btrfs csum failed, scrub ok Christoph Groth
2012-03-27 11:08 ` 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
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.