sanity check: is 9211-8i, on 8.3, with IT firmware still "the one"

[Jeremy Chadwick]

On Fri, Jan 20, 2012 at 10:36:30AM +0100, Peter Maloney wrote:
> On 01/20/2012 10:09 AM, Jeremy Chadwick wrote:
> > And media confirmations:
> >
> > http://www.theverge.com/2012/1/17/2713178/crucial-m4-ssd-firmware-update-fixes-recurring-bsod
> > http://www.anandtech.com/show/5308/crucial-to-fix-m4-bsod-issue-in-two-weeks
> > http://www.anandtech.com/show/5424/crucial-provides-a-firmware-update-for-m4-to-fix-the-bsod-issue
> >
> > I've now added Crucial to my SSD brands to avoid (currently OCZ and
> > Crucial).  Welcome to year 20xx, where nobody actually does quality
> > assurance properly.
>
> What is your problem with OCZ SSDs?

Extremely high failure rate compared to other vendors (Intel was the
best until the recent 320-series "8MByte capacity" firmware fiasco), and
all sorts of performance problems all across the board.  Every single
time I hear about a new OCZ SSD product, I wait 8-10 weeks and suddenly
there's some sort of major bug/quirk found with it.  I grew tired of
following the trend.  I don't know how else to describe it, honestly.
If others are cool with it, that's fine -- honest, no argument, everyone
should make their own decisions based on what works for them.  But for
me, it doesn't jibe.

What I've been doing for years with a pretty good success rate: before
considering any "consumer" product (especially if product reliability
matters in your environment, e.g. you don't have HA or 200 spare
fail-over boxes available at any moment), visit the Support Forum of the
vendor, subcategory relating to the item you're interested in.  Spend a
few hours over the course of 3-4 weeks reading end-user reports and
experiences.  Yes, I am well aware that most end-users cannot diagnose
problems worth a damn, but it doesn't matter -- all you have to look for
is common trends in reports to get a feel for something.

If you aren't left with that "warm fuzzy" feeling (SAs here should know
what I mean), take note of your reasons and move on to another product.
When a colleague (not someone online) asks you "What do you mean you
don't like FooProduct?" you can say "here's why".

This is what I did before choosing to invest in Intel SSDs for our
servers, as well as for my workstation (Windows box) and my home FreeBSD
box.

I even did the latter with regards to some perl software I wrote for my
own purposes.  I went looking for a config file parsing perl module that
did what I needed.  I tried 15 modules.  FIFTEEN OF THEM.  I began to
lose track which ones I tried and why they sucked.  So, in the software
repo of the program I wrote, I made this file:

-rw-------    1 jdc       users        4368 Mar  5  2008 horrible_perl_modules.txt

Which documented the shortcomings/issues I had with them.  A few years
later, someone asked me for this program I wrote so I sent them a
tarball.  The following morning I had a mail from them saying "Oh my
god, horrible_perl_modules.txt!  I wish more people did write-ups like
this in their software explaining why they used ThingA and why
Thing[XYZ] didn't work *for this program specifically*!"  Yeah well,
that's just how I operate.

Back to my method -- it's in no way shape or form fail-proof.  For
example, I have two Intel 320-series SSDs that have not been bit by the
"8MByte capacity" bug but I pulled them out of use the INSTANT Intel
confirmed its existence and replaced them with either X25-M or
510-series units.  I didn't jump on the Intel Cougar Point bandwagon (I
waited a year), thus avoided the SATA-related B2 stepping bug (who will
remember that in years to come?).

But I can't tell you how many times I've sighed and said "dodged that
bullet!"  It's far from perfect, but it's a hell of a lot better than
making a decision based on some biased hardware review site benchmarks,
or even word-of-mouth (which matters a lot, but only if the person who's
selling you the product has the same belief system you do ;-) ).  You
have to visit the Support Forums, it's really the only way you'll know
of what trouble you might be getting yourself into -- and you can then
determine if that risk is worth it or not.  If it is, as I said, totally
cool.  If it isn't, also cool.  Whatever works for you!

When it comes to products, I don't tolerate vendors' "hey, mistakes
happen" behaviour, and (when I can) I speak with my wallet, because at
the end of the day that's really the only way to "talk" to a vendor.
All this stuff is made by humans, and we're not perfect beings.  I
accept that.  Certain technology today is more reliable than it was
20-25 years ago, while other technology isn't.  We've had to make a lot
of trade-offs as technology has evolved though, and some (most?) of
those I do not agree with.  It's all about quality assurance and decent
testing or lack thereof.  It often shocks me how many companies have QA
departments who only test what they're shown/told to test and not
actually assure quality.  So many QA divisions do not understand the
innards of what they're testing; "run this script, look at these
numbers" seems to be the modus operandi.  We've got it all wrong.

Finally, please note: I am in no way shape or form an "Intel fanboy".  I
use whatever products I choose at the time.  I'd rather not cite
examples in this mail (it's long enough as is), nor privately, but
believe me, I have a list of lots of products, and a shorter list of
actual vendors/manufacturers that I avoid.  A year from now those lists
might be different based on what I witness, discover, or even try.  You
might even find some of my examples on the web if you look hard enough.

For me, it feels like it boils down to one thing: I am a dying breed of
system administrator and technician.  In today's technology/IT world,
the mentality is that everything is expendable, everything will fail
(and more importantly don't bother figuring out **why**, just replace it
and pretend it didn't happen; solve nothing, bury head in ground).  I
feel like I'm one of those rare few who was taught skills based on a
foundation of KISS principle and actually *solving problems* rather than
saying "f-it" and accepting them as "technology is just flaky".  I
wasn't raised, educated, nor trained to accept that excuse.  I guess
that's why I consider myself a technophobe; I feel more and more like
H.P. Lovecraft every time I have to deal with a bug in, well, anything.

Anyway, that's all from me on the matter.  I won't be replying past this
point; there just isn't much for me to say.  (Sorry, I've had a very,
VERY long week...)

-- 
| Jeremy Chadwick                                 jdc at parodius.com |
| Parodius Networking                     http://www.parodius.com/ |
| UNIX Systems Administrator                 Mountain View, CA, US |
| Making life hard for others since 1977.             PGP 4BD6C0CB |