From: Bill Davidsen <davidsen@tmr.com>
To: David Lethe <david@santools.com>
Cc: "Keld Jørn Simonsen" <keld@dkuug.dk>,
"Ty! Boyack" <ty@nrel.colostate.edu>,
linux-raid@vger.kernel.org
Subject: Re: managing raid on Linux
Date: Sat, 26 Apr 2008 15:39:09 -0400 [thread overview]
Message-ID: <481384DD.9040801@tmr.com> (raw)
In-Reply-To: <A20315AE59B5C34585629E258D76A97C19652E@34093-C3-EVS3.exchange.rackspace.com>
David Lethe wrote:
> -----Original Message-----
> From: Keld Jørn Simonsen [mailto:keld@dkuug.dk]
> Sent: Wednesday, April 23, 2008 1:47 PM
> To: David Lethe
> Cc: Ty! Boyack; linux-raid@vger.kernel.org
> Subject: Re: managing raid on Linux
>
> On Wed, Apr 23, 2008 at 01:17:19PM -0500, David Lethe wrote:
>
>> Well, this is the norm. While some APIs are well done, the other
>> extreme is that vendor xyz farmed out the API/drivers to another
>> company, and the hardware vendor doesn't have the resources, knowledge
>> or experience to provide the information necessary to bring a 3rd-party
>> management tool to market. I will certainly not reveal anything about
>> the companies that did farm out the software/firmware to 3rd parties,
>> and will not tell you if their names were mentioned in this post.
>> Suffice to say that this is a real problem with SOME controllers that
>> people reading this post have installed in their computers.
>>
>> - The economics of developing support for a particular controller is a
>> severe constraint. Consider the reasons above, and then add simple
>> equipment costs for development/testing, and then support. I'm not
>> going to add support for product xyz unless I know it will be
>> profitable, and even a hundred end-user requests won't begin to pay for
>> such an effort.
>>
>> - I for one certainly can't keep up with all the new things coming
>> out, so we choose our battles wisely based on the market opportunity,
>> longevity of the controller platform, safety/robustness of the API, and
>> development/ongoing support expense.
>>
>> So there are the reasons why the OP can't find anything that supports
>> everything he has.
>>
>
> David, thanks for your explanation of the current situation for making
> an übermanageri for HW RAID. The prospects seem dark indeed.
>
>
If there were an ubermanager then products could compete on only price
and performance. Now they can compete on ease of use as well, and that's
not all bad for the customer. Corporations try to skimp on system
management (usually) and often ease of use is the differerce between
mediocre management and totally incompetent.
> Are there then more future in doing it the SW RAID way, as the Linux
> Kernel stuff we are discussion here on this mailing list?
>
>
The advantage is in the portability, you need not spend the top dollar
on hardware to get quite good results.
> Are there chances that this work om Linux RAID can match or be better
> on the issues of performance, raid personality flavours and management,
> compared to the best of the HW RAID manufacturers?
>
>
No, not the best. The reason is that Raid-N, where N>0, writes recovery
information, either mirrors or CRCs, or similar. Software raid must pass
this as multiple writes, opening a chance for consistency problems, and
always taking more bus bandwidth. So better than the best dedicated
hardware it is not, and can't be. As good as the "very good" hardware
solutions, yes. More flexible to expanding with whatever hardware is
cost effective when you need it, SW raid wins every time.
--
Bill Davidsen <davidsen@tmr.com>
"Woe unto the statesman who makes war without a reason that will still
be valid when the war is over..." Otto von Bismark
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
prev parent reply other threads:[~2008-04-26 19:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-20 21:51 managing raid on linux devzero
2008-04-23 15:00 ` Bill Davidsen
2008-04-23 15:55 ` Ty! Boyack
2008-04-23 18:17 ` managing raid on Linux David Lethe
[not found] ` <20080423184722.GA4889@rap.rap.dk>
2008-04-23 19:21 ` David Lethe
2008-04-26 19:39 ` Bill Davidsen [this message]
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=481384DD.9040801@tmr.com \
--to=davidsen@tmr.com \
--cc=david@santools.com \
--cc=keld@dkuug.dk \
--cc=linux-raid@vger.kernel.org \
--cc=ty@nrel.colostate.edu \
/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).