From: "Eric M. Hopper" <hopper@omnifarious.mn.org>
To: linux-lvm@msede.com
Subject: Re: [linux-lvm] LVM 0.8 and reiser filesystem
Date: Wed, 7 Jun 2000 08:53:13 -0500 [thread overview]
Message-ID: <20000607085313.A30493@omnifarious.mn.org> (raw)
In-Reply-To: <20000607140043.B5442@colombina.comedia.it>; from bluca@comedia.it on Wed, Jun 07, 2000 at 02:00:43PM +0200
[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]
On Wed, Jun 07, 2000 at 02:00:43PM +0200, Luca Berra wrote:
> On Tue, Jun 06, 2000 at 06:41:38PM +0200, Andi Kleen wrote:
>> On a real production system you probably should not use software
>> RAID1 or RAID5 though. It is unreliable in the crash case though
>> because it does not support data logging. In this case a hardware
>> RAID controller is the better alternative. Of course you can run LVM
>> on top of it.
>
> I fail to get your point, what makes hw raid more reliable than sw
> raid? why are you saying that sw raid is unreliable.
Because in RAID1 or 5 (mirroring, or striping with parity), you
have to write both mirrored sectors, or a sector and its parity sector
in one transaction. Both must be at least attempted. If one fails,
that drive needs to be flagged as bad.
In software RAID, software failures can cause this not to
happen. The kernel might panic at the wrong time, the power might go
out, etc, etc. If you do it in hardware, you can use capacitors to make
sure the hardware stays up long enough to complete the transaction and
there are fewer things in the chain to fail.
Since the whole point of RAID5, and especially RAID1 is
reliability, implementing them in ways that reduce reliability is very
questionable.
Implementing RAID0 (simple striping) in software is just fine.
Simple striping actually reduces reliability, and is only done for
speed. Implementing it in software does not significantly reduce
reliability beyond the amount it's reduced by having two drives that
could fail instead of one.
Have fun (if at all possible),
--
Its name is Public Opinion. It is held in reverence. It settles everything.
Some think it is the voice of God. Loyalty to petrified opinion never yet
broke a chain or freed a human soul. ---Mark Twain
-- Eric Hopper (hopper@omnifarious.mn.org http://www.omnifarious.org/~hopper) --
[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]
next prev parent reply other threads:[~2000-06-07 13:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-06-06 15:44 [linux-lvm] LVM 0.8 and reiser filesystem holger_zecha
2000-06-06 16:21 ` Luca Berra
2000-06-06 16:29 ` Brian Kress
2000-06-06 16:41 ` Andi Kleen
2000-06-07 12:00 ` Luca Berra
2000-06-07 12:59 ` Andi Kleen
2000-06-07 15:34 ` Luca Berra
2000-06-07 16:14 ` Andi Kleen
2000-06-07 16:04 ` Jos Visser
2000-06-07 16:08 ` Andi Kleen
2000-06-07 16:23 ` Jos Visser
2000-06-07 13:53 ` Eric M. Hopper [this message]
2000-06-06 17:33 ` Eric M. Hopper
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=20000607085313.A30493@omnifarious.mn.org \
--to=hopper@omnifarious.mn.org \
--cc=linux-lvm@msede.com \
/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).