From: Martin Schitter <ms@mur.at>
To: Edward Ned Harvey <kernel@nedharvey.com>
Cc: cwillu <cwillu@cwillu.com>, "Fajar A. Nugraha" <list@fajar.net>,
linux-btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: btrfs csum failed
Date: Wed, 04 May 2011 16:42:51 +0200 [thread overview]
Message-ID: <4DC165EB.7060304@mur.at> (raw)
In-Reply-To: <000e01cc0a5e$7446eab0$5cd4c010$@nedharvey.com>
Am 2011-05-04 15:23, schrieb Edward Ned Harvey:
>> From: linux-btrfs-owner@vger.kernel.org [mailto:linux-btrfs-
>> owner@vger.kernel.org] On Behalf Of Martin Schitter
>>
>> well -- i am doing a backup of all images every night. this
>> process should work like a simple "scrub" because all data (and its
>> checksumes) will be read.
>
> Sorry, not correct. When you read all the data using something in
> user-land, the OS only needs to read one side of the data. It can
> accelerate by staggering the read requests across multiple disks. So
> some sectors remain unread on some disks.
>
> When you scrub, it reads all the data from all the redundant copies
> (mirrored or raid) on all the individual disks in the raid set.
ok -- i see -- you're right!
i know, there a some befits in the way btrfs and zfs implement RAID /
multiply disk usage and checksumming, but i a also want to stay on the
save side, when it comes to real practical problems. so i decided to use
'classical' linux software RAID-1 as the base layer. that's a very old
fashioned solution, but it usually simply works... and you can change a
broken disk without any respect of the used filesystem(s). in general i
try to use btrfs only on account of its snapshot features in a very
simple way.
it looks very strange to me, that i don't see any SMART warnings on the
harddisks or errors on other filsystems on the same raid-array. there
was also no reboot, power-failure or similar when the corruption
suddenly appeared. so i think, a btrfs bug would be the most evident
explanation.
martin
next prev parent reply other threads:[~2011-05-04 14:42 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-03 21:56 btrfs csum failed Martin Schitter
2011-05-04 0:28 ` Josef Bacik
2011-05-04 0:44 ` Martin Schitter
2011-05-04 2:18 ` Fajar A. Nugraha
2011-05-04 11:39 ` Martin Schitter
2011-05-04 11:47 ` Hugo Mills
2011-05-04 11:51 ` cwillu
2011-05-04 12:27 ` Martin Schitter
2011-05-04 13:23 ` Edward Ned Harvey
2011-05-04 14:42 ` Martin Schitter [this message]
2011-05-04 18:10 ` Chris Mason
2011-05-04 14:09 ` Jan Schmidt
2011-05-04 12:31 ` Kaspar Schleiser
2011-05-04 13:25 ` Martin Schitter
2011-05-04 14:39 ` Josef Bacik
2011-05-04 12:39 ` Chris Mason
2011-05-04 14:06 ` Martin Schitter
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=4DC165EB.7060304@mur.at \
--to=ms@mur.at \
--cc=cwillu@cwillu.com \
--cc=kernel@nedharvey.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=list@fajar.net \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).