From: Ed W <lists@wildgooses.com>
To: Rudy Zijlstra <rudy@grumpydevil.homelinux.org>
Cc: Stan Hoeppner <stan@hardwarefreak.com>, linux-raid@vger.kernel.org
Subject: Re: HBA Adaptor advice
Date: Sat, 21 May 2011 12:54:52 +0100 [thread overview]
Message-ID: <4DD7A80C.8050808@wildgooses.com> (raw)
In-Reply-To: <4DD7A205.8070106@grumpydevil.homelinux.org>
Hi
> I understand your thinking. There is one big cost not mentioned in this
> calculation though:
> - what is the cost if the data is lost/corrupt?
I think it's fair to say that the loss of all your business data is the
loss of your entire business?!
That said if you are Skype you don't spend 8.5 billion on raid cards,
instead you choose a layered approach to availability which normally
trades speed of restore time vs cost.
Eg one might specify raid 6, dual mirrored servers, backed up to some
spare disks, blueray and some offsite storage service. This would give
resilliance to various types of disaster without spending the entire
budget on a fancy raid card?
In fact if you go back to my question, the *entire* point is that I
don't want the choice of card to be a point of failure, ie it's my
specific point to purchase a card such that it can be swapped out for
near any other card in the event of failure.
> compared to that cost, how relevant is the cost of a proper card?
See point above. I don't get a strong feeling that a "proper card" is
any more reliable and resiliant than a well chosen cheap card? If that
theory is correct then the ability to swap in another cheap card in the
event of disaster is valuable and eliminates a point of failure for
little cost?
> I am getting the feeling of "penny wise, pound foolish"
I don't see that your logic leads here?
There is a clear definition of good/bad here. The only acceptable
performance is that all reads/writes are accurate and completed. No
data should be lost or corrupted. Assuming that the market can be
partitioned into good/bad cards based on the definition above, then if
we select from only "good" cards, then price appears to only buy me
performance, nothing else?
So my question is how to choose from all the "good" cards, the best bang
for buck. I don't see any reason not to buy a cheaper card that
performs well, subject to it being reliable and doesn't loose data.
Does someone have a claim that dataloss is actually on a curve and that
more expensive cards corrupt less data and cheaper cards corrupt more
data... That doesn't seem to fit with expectation... (I expect either
working cards that loose nothing, or bad cards that loose some data.
Black and white)
> Now that mind set, of course, describes many a business....
I think this is a silly line of argument. All you can ever do is buy
"insurance" against low probability events occuring. Annoyingly the
"insurance" in this scenario doesn't always pay out and so the question
is how much to spend on orthogonal types of insurance to increase the
chance of a payout in the case of disaster...
It's always easy in the event of some disaster to point out how you
should have bought some different type of "insurance", but equally it's
also dead money that a business could spend to generate income...
Balancing funding between profitable activities and insurance is a fine
line (especially since you are insuring against infrequent events)
As engineers, yes it's always easy to prefer to spend money on technical
"insurance", but accept also that there are competing demands on where
cash gets deployed to earn a return?
Cheers
Ed W
next prev parent reply other threads:[~2011-05-21 11:54 UTC|newest]
Thread overview: 60+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-19 12:26 HBA Adaptor advice Ed W
2011-05-19 12:36 ` Roman Mamedov
2011-05-19 12:43 ` Mathias Burén
2011-05-19 14:06 ` Michael Sallaway
2011-05-19 19:10 ` Thomas Harold
2011-05-19 21:12 ` Rudy Zijlstra
2011-05-19 21:07 ` Brad Campbell
2011-05-20 20:58 ` Tobias McNulty
2011-05-20 21:23 ` Brad Campbell
2011-05-20 2:08 ` Andy Smith
2011-05-20 5:30 ` Stan Hoeppner
2011-05-21 9:52 ` Ed W
2011-05-20 7:33 ` Ed W
2011-05-20 10:21 ` Stan Hoeppner
2011-05-21 11:17 ` Ed W
2011-05-21 11:29 ` Rudy Zijlstra
2011-05-21 11:54 ` Ed W [this message]
2011-05-21 17:37 ` Leslie Rhorer
2011-05-22 9:41 ` Stan Hoeppner
2011-05-22 10:03 ` Rudy Zijlstra
2011-05-23 9:32 ` Ed W
2011-05-21 17:05 ` Leslie Rhorer
2011-05-22 9:04 ` Stan Hoeppner
2011-05-22 10:09 ` Brad Campbell
2011-05-22 19:25 ` Stan Hoeppner
2011-05-22 20:57 ` Tobias McNulty
2011-05-22 21:13 ` Johannes Truschnigg
2011-05-23 9:48 ` Ed W
2011-05-23 10:44 ` John Robinson
2011-05-22 23:19 ` Brad Campbell
2011-05-23 4:09 ` Roman Mamedov
2011-05-23 5:54 ` Brad Campbell
2011-05-23 6:08 ` Roman Mamedov
2011-05-23 10:42 ` Stan Hoeppner
2011-05-23 11:35 ` David Brown
2011-05-23 6:54 ` Stan Hoeppner
2011-05-23 7:23 ` Brad Campbell
2011-05-22 23:44 ` Brad Campbell
2011-05-23 0:07 ` Brad Campbell
2011-05-23 5:30 ` Stefan /*St0fF*/ Hübner
2011-05-23 10:18 ` Ed W
2011-05-23 9:58 ` Stan Hoeppner
2011-05-23 10:33 ` Ed W
2011-05-23 11:21 ` Stan Hoeppner
2011-05-20 12:18 ` Joe Landman
2011-05-20 12:34 ` Roman Mamedov
2011-05-20 12:36 ` Mathias Burén
2011-05-20 12:48 ` Joe Landman
2011-05-20 13:21 ` Ed W
2011-05-20 14:23 ` Joe Landman
2011-05-20 20:01 ` Andy Smith
2011-05-20 20:12 ` Stan Hoeppner
2011-05-20 20:24 ` Drew
2011-05-20 20:58 ` Stan Hoeppner
[not found] ` <4DD7A100.2010807@wildgooses.com>
2011-05-22 8:13 ` Stan Hoeppner
-- strict thread matches above, loose matches on Subject: below --
2011-05-23 2:11 Jim Schatzman
2011-05-23 3:39 ` Tobias McNulty
2011-05-23 10:42 ` Ed W
2011-05-23 11:14 HBA Adaptor Advice Ed W
2011-05-23 11:55 ` Joe Landman
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=4DD7A80C.8050808@wildgooses.com \
--to=lists@wildgooses.com \
--cc=linux-raid@vger.kernel.org \
--cc=rudy@grumpydevil.homelinux.org \
--cc=stan@hardwarefreak.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 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.