From: Andi Kleen <ak@muc.de>
To: linux-kernel@vger.kernel.org
Cc: linux-kernel@plan9.de
Subject: Re: critical bugs in md raid5
Date: Thu, 27 Jan 2005 06:11:34 +0100 [thread overview]
Message-ID: <m1vf9j4fsp.fsf@muc.de> (raw)
In-Reply-To: <20050127035906.GA7025@schmorp.de> (Marc Lehmann's message of "Thu, 27 Jan 2005 04:59:07 +0100")
Marc Lehmann <linux-kernel@plan9.de> writes:
>
> The summary seems to be that the linux raid driver only protects your data
> as long as all disks are fine and the machine never crashes.
"as long as the machine never crashes". That's correct. If you think
about how RAID 5 works there is no way around it. When a write to
a single stripe is interrupted (machine crash) and you lose a disk
during the recovery a lot of data (even unrelated to the data just written)
is lost. That is because there is no way to figure out what part
of the data on the stripe belonged to the old and what part to
the new write.
But that's nothing inherent in Linux RAID5. It's a generic problem.
Pretty much all Software RAID5 implementations have it.
The only way around it is to journal all writes, to make stripe
updates atomic, but in general that's too slow unless you have a
battery backed up journal device.
There are some tricks to avoid this (e.g. always write to a new disk
location and update an disk index atomically), but they tend to be
heavily patented and are slower too. They also go far beyond RAID-5
(use disk space less efficiently etc.) and typically need support
from the file system to be efficient.
RAID-1 helps a bit, because you either get the old or the new data,
but not some corruption. In practice even old data can be a big
problem though (e.g. when file system metadata is affected)
Morale: if you really care about your data backup very often and
use RAID-1 or get an expensive hardware RAID with battery backup
(all the cheap "hardware RAIDs" are equally useless for this)
-Andi
next prev parent reply other threads:[~2005-01-27 5:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-27 3:59 critical bugs in md raid5 Marc Lehmann
2005-01-27 5:11 ` Andi Kleen [this message]
2005-01-27 6:31 ` Marc Lehmann
2005-01-27 9:51 ` Andi Kleen
2005-01-27 16:33 ` critical bugs in md raid5 and ATA disk failure/recovery modes Marc Lehmann
2005-01-29 18:35 ` Pavel Machek
2005-01-29 18:37 ` Andi Kleen
2005-01-29 18:55 ` Pavel Machek
2005-01-27 16:56 ` critical bugs in md raid5 Lehmann
2005-01-27 6:48 ` Lehmann
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=m1vf9j4fsp.fsf@muc.de \
--to=ak@muc.de \
--cc=linux-kernel@plan9.de \
--cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox